В одном из проектов мне пришлось столкнуться с классической ситуацией: нагрузка со стороны приложения на реляционную БД была чрезвычайно высока из-за большого RPS (requests per second). Однако реальный процент уникальных данных, извлекаемых приложением из БД, был относительно невелик. К тому же, медленный ответ БД порождал рост числа подключений к ней со стороны приложения — это еще больше увеличивало нагрузку и вызвало эффект снежного кома.
Выбранное решение для этой проблемы закономерно: кэширование данных. В роли кэша выступило хранилище memcached, которое приняло на себя основную нагрузку от запросов на получение данных. Однако при переезде приложения в Kubernetes возникли сложности…
Я стал изучать причину возросших задержек и понял, что они связаны исключительно с сетевой конфигурацией. Если раньше приложение и memcached находились на одном физическом узле, то в K8s-кластере Pod с приложением и Pod с memcached чаще всего оказывались на разных узлах. В таких случаях неизбежны сетевые задержки.
Очевидно, что memcached необходимо запускать в DaemonSet на тех же узлах, на которых работает приложение, а значит — потребуется настройка node affinity. Чтобы конфигурация была интересной, прикладываю приближенный к production листинг, в котором можно также увидеть probes и requests/limits:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: mc
labels:
app: mc
spec:
selector:
matchLabels:
app: mc
template:
metadata:
labels:
app: mc
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: node-role.kubernetes.io/node
operator: Exists
containers:
- name: memcached
image: memcached:1.6.9
command:
- /bin/bash
- -c
- --
- memcached --port=30213 --memory-limit=2048 -o modern v --conn-limit=4096 -u memcache
ports:
- name: mc-production
containerPort: 30213
livenessProbe:
tcpSocket:
port: mc-production
initialDelaySeconds: 30
timeoutSeconds: 5
readinessProbe:
tcpSocket:
port: mc-production
initialDelaySeconds: 5
timeoutSeconds: 1
resources:
requests:
cpu: 100m
memory: 2560Mi
limits:
memory: 2560Mi
---
apiVersion: v1
kind: Service
metadata:
name: mc
spec:
selector:
app: mc
clusterIP: None
publishNotReadyAddresses: true
ports:
- name: mc-production
port: 30213
Но у приложения есть дополнительное требование к когерентности кэша. Данные во всех экземплярах кэша должны точно соответствовать данным в реляционной БД. В приложении есть механизм, который в обязательном порядке при обновлении в БД кэшируемых данных также обновляет их и в memcached. Следовательно, нам необходимо обеспечить механизм, который транслировал бы обновления кэша, произведенные экземпляром приложения на одном из узлов, на все остальные узлы. Для этого в качестве прослойки между приложением и memcached прекрасно подходит mcrouter — маршрутизатор для масштабирования memcached-инсталляций. Мы уже даже писали о нем статью.
Но чтобы повысить отказоустойчивость, лучше выделить mcrouter в отдельный DaemonSet и вынести memcached и mcrouter в hostNetwork. При таком разделении любые проблемы с каким-либо экземпляром memcached не повлияют на доступность кэша для приложения. Перевыкат как для memcached, так и для mcrouter можно выполнять раздельно, что повышает отказоустойчивость всей системы при таких операциях.
Чтобы выделить memcached в hostNetwork, добавим в манифест: hostNetwork: true.
Также добавим переменную окружения с IP-адресом узла, на котором запущен Pod, в контейнер с memcached:
env:
- name: HOST_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
И модифицируем команду запуска memcached, чтобы порт был открыт только на внутреннем IP кластера:
command:
- /bin/bash
- -c
- --
- memcached --listen=$HOST_IP --port=30213 --memory-limit=2048 -o modern v --conn-limit=4096 -u memcache
Аналогично опишем DaemonSet mcrouter’a, Pod’ы которого также должны запускаться в hostNetwork:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: mcrouter
labels:
app: mcrouter
spec:
selector:
matchLabels:
app: mcrouter
template:
metadata:
labels:
app: mcrouter
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: node-role.kubernetes.io/node
operator: Exists
hostNetwork: true
imagePullSecrets:
- name: "registrysecret"
containers:
- name: mcrouter
image: {{ .Values.werf.image.mcrouter }}
command:
- /bin/bash
- -c
- --
- mcrouter --listen-addresses=$HOST_IP --port=31213 --config-file=/mnt/config/config.json --stats-root=/mnt/config/
volumeMounts:
- name: config
mountPath: /mnt/config
ports:
- name: mcr-production
containerPort: 30213
livenessProbe:
tcpSocket:
port: mcr-production
initialDelaySeconds: 30
timeoutSeconds: 5
readinessProbe:
tcpSocket:
port: mcr-production
initialDelaySeconds: 5
timeoutSeconds: 1
resources:
requests:
cpu: 300m
memory: 100Mi
limits:
memory: 100Mi
env:
- name: HOST_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
volumes:
- configMap:
name: mcrouter
name: mcrouter
- name: config
emptyDir: {}
Поскольку mcrouter тоже запущен в hostNetwork, для него также сделано ограничение, чтобы порт открывался только на внутреннем IP узлов.
Вариант сборки mcrouter, как мы это делаем с помощью werf (не составит труда переписать на обычный Dockerfile, если такая необходимость есть):
image: mcrouter
from: ubuntu:18.04
mount:
- from: tmp_dir
to: /var/lib/apt/lists
ansible:
beforeInstall:
- name: Install prerequisites
apt:
name:
- apt-transport-https
- apt-utils
- dnsutils
- gnupg
- tzdata
- locales
update_cache: yes
- name: Add mcrouter APT key
apt_key:
url: https://facebook.github.io/mcrouter/debrepo/bionic/PUBLIC.KEY
- name: Add mcrouter Repo
apt_repository:
repo: deb https://facebook.github.io/mcrouter/debrepo/bionic bionic contrib
filename: mcrouter
update_cache: yes
- name: Set timezone
timezone:
name: "Europe/Moscow"
- name: Ensure a locale exists
locale_gen:
name: en_US.UTF-8
state: present
install:
- name: Install mcrouter
apt:
name:
- mcrouter
И самое интересное — это конфигурационный файл mcrouter. Он должен генерироваться на лету, при запуске Pod’а на конкретном узле, чтобы подставить адрес «своего» узла как приоритетный для чтения. Для этого необходим init-контейнер в Pod’е с mcrouter’ом, который генерирует конфигурационный файл и подкладывает его в общий volume в emptyDir:
initContainers:
- name: init
image: {{ .Values.werf.image.mcrouter }}
command:
- /bin/bash
- -c
- /mnt/config/config_generator.sh /mnt/config/config.json
volumeMounts:
- name: mcrouter
mountPath: /mnt/config/config_generator.sh
subPath: config_generator.sh
- name: config
mountPath: /mnt/config
env:
- name: HOST_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
Вот так может выглядеть сам генератор конфигурационного файла, который выполняется в init-контейнере:
apiVersion: v1
kind: ConfigMap
metadata:
name: mcrouter
data:
config_generator.sh: |
#!/bin/bash
set -e
set -o pipefail
config_path=$1;
if [ -z "${config_path}" ]; then echo "config_path isn't specified"; exit 1; fi
function join_by { local d=$1; shift; local f=$1; shift; printf %s "$f" "${@/#/$d}"; }
mapfile -t ips < <( host mc.production.svc.cluster.local 10.222.0.10 | grep mc.production.svc.cluster.local | awk '{ print $4; }' | sort | grep -v $HOST_IP )
delimiter=':30213","'
servers='"'$(join_by $delimiter $HOST_IP "${ips[@]}")':30213"'
cat <<< '{
"pools": {
"A": {
"servers": [
'$servers'
]
}
},
"route": {
"type": "OperationSelectorRoute",
"operation_policies": {
"add": "AllSyncRoute|Pool|A",
"delete": "AllSyncRoute|Pool|A",
"get": "FailoverRoute|Pool|A",
"set": "AllSyncRoute|Pool|A"
}
}
}
' > $config_path
Скрипт обращается к внутреннему DNS в K8s-кластере, получает все IP-адреса для Pod’ов memcached и формирует список адресов. Первый в списке — IP-адрес того узла, на котором запущен наш экземпляр mcrouter.
Обратите внимание! Для того, чтобы при обращении к DNS были получены адреса Pod’ов, в приведенном выше манифесте Service для memcached указана спецификация clusterIP: None.
Результат работы скрипта:
cat /mnt/config/config.json
{
"pools": {
"A": {
"servers": [
"192.168.100.33:30213","192.168.100.14:30213","192.168.100.15:30213","192.168.100.16:30213","192.168.100.21:30213","192.168.100.22:30213","192.168.100.23:30213","192.168.100.34:30213"
]
}
},
"route": {
"type": "OperationSelectorRoute",
"operation_policies": {
"add": "AllSyncRoute|Pool|A",
"delete": "AllSyncRoute|Pool|A",
"get": "FailoverRoute|Pool|A",
"set": "AllSyncRoute|Pool|A"
}
}
}
Так мы обеспечиваем синхронизацию записи изменений на все экземпляры memcached и приоритетное чтение со «своего» узла.
NB. Если строгого требования к когерентности кэша нет, то для большей скорости работы и меньшей чувствительности к нестабильности кластера в целом рекомендуется вместо AllSyncRoute использовать дескриптор маршрута AllMajorityRoute или даже AllFastestRoute.
Вариант решения: в Pod’е с mcrouter’ом сделать sidecar-контейнер с cron’ом, по которому бы делалась проверка списка узлов и применялись изменения.
Конфигурация sidecar’а:
- name: cron
image: {{ .Values.werf.image.cron }}
command:
- /usr/local/bin/dumb-init
- /bin/sh
- -c
- /usr/local/bin/supercronic -json /app/crontab
volumeMounts:
- name: mcrouter
mountPath: /mnt/config/config_generator.sh
subPath: config_generator.sh
- name: mcrouter
mountPath: /mnt/config/check_nodes.sh
subPath: check_nodes.sh
- name: mcrouter
mountPath: /app/crontab
subPath: crontab
- name: config
mountPath: /mnt/config
resources:
limits:
memory: 64Mi
requests:
memory: 64Mi
cpu: 5m
env:
- name: HOST_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
Скрипты, работающие в этом cron’е, вызывают тот же самый config_generator.sh, который используется в init-контейнере:
crontab: |
# Check nodes in cluster
* * * * * * * /mnt/config/check_nodes.sh /mnt/config/config.json
check_nodes.sh: |
#!/usr/bin/env bash
set -e
config_path=$1;
if [ -z "${config_path}" ]; then echo "config_path isn't specified"; exit 1; fi
check_path="${config_path}.check"
checksum1=$(md5sum $config_path | awk '{print $1;}')
/mnt/config/config_generator.sh $check_path
checksum2=$(md5sum $check_path | awk '{print $1;}')
if [[ $checksum1 == $checksum2 ]]; then
echo "No changes for nodes."
exit 0;
else
echo "Node list was changed."
mv $check_path $config_path
echo "mcrouter is reconfigured."
fi
Раз в секунду вызывается скрипт, который генерирует конфигурационный файл для mcrouter. При изменении контрольной суммы конфигурационного файла обновленный файл подкладывается mcrouter’у через общий между контейнерами каталог в emptyDir. Дополнительно заставлять mcrouter обновлять конфигурацию не требуется, т. к. он сам перечитывает свой конфигурационный файл раз в секунду.
Теперь осталось только в Pod’е с приложением указать IP-адрес самого узла — в переменной окружения, в которой указывается адрес memcached. А в качестве порта memcached указать порт mcrouter’a:
env:
- name: MEMCACHED_HOST
valueFrom:
fieldRef:
fieldPath: status.hostIP
- name: MEMCACHED_PORT
value: 31213
Состояние до оптимизации:
После оптимизации:
Решение применяется в production примерно полгода, и за это время подводных камней не всплыло.
Итоговые листинги, упомянутые в статье (Helm-чарты и werf.yaml), доступны в репозитории flant/examples.
habr.com
Выбранное решение для этой проблемы закономерно: кэширование данных. В роли кэша выступило хранилище memcached, которое приняло на себя основную нагрузку от запросов на получение данных. Однако при переезде приложения в Kubernetes возникли сложности…
Проблема
После миграции в K8s проект выиграл в целом за счет легкости масштабирования и прозрачности работы выбранной схемы с кэшированием. Однако средняя отзывчивость приложения снизилась. Анализ производительности средствами New Relic показал, что после переезда заметно выросло время, которое приложение стало проводить в memcached.Я стал изучать причину возросших задержек и понял, что они связаны исключительно с сетевой конфигурацией. Если раньше приложение и memcached находились на одном физическом узле, то в K8s-кластере Pod с приложением и Pod с memcached чаще всего оказывались на разных узлах. В таких случаях неизбежны сетевые задержки.
Решение
NB. Предложенная ниже методика проверена в production-кластере с 10 экземплярами memcached. На более масштабных инсталляциях решение не проверялось.Очевидно, что memcached необходимо запускать в DaemonSet на тех же узлах, на которых работает приложение, а значит — потребуется настройка node affinity. Чтобы конфигурация была интересной, прикладываю приближенный к production листинг, в котором можно также увидеть probes и requests/limits:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: mc
labels:
app: mc
spec:
selector:
matchLabels:
app: mc
template:
metadata:
labels:
app: mc
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: node-role.kubernetes.io/node
operator: Exists
containers:
- name: memcached
image: memcached:1.6.9
command:
- /bin/bash
- -c
- --
- memcached --port=30213 --memory-limit=2048 -o modern v --conn-limit=4096 -u memcache
ports:
- name: mc-production
containerPort: 30213
livenessProbe:
tcpSocket:
port: mc-production
initialDelaySeconds: 30
timeoutSeconds: 5
readinessProbe:
tcpSocket:
port: mc-production
initialDelaySeconds: 5
timeoutSeconds: 1
resources:
requests:
cpu: 100m
memory: 2560Mi
limits:
memory: 2560Mi
---
apiVersion: v1
kind: Service
metadata:
name: mc
spec:
selector:
app: mc
clusterIP: None
publishNotReadyAddresses: true
ports:
- name: mc-production
port: 30213
Но у приложения есть дополнительное требование к когерентности кэша. Данные во всех экземплярах кэша должны точно соответствовать данным в реляционной БД. В приложении есть механизм, который в обязательном порядке при обновлении в БД кэшируемых данных также обновляет их и в memcached. Следовательно, нам необходимо обеспечить механизм, который транслировал бы обновления кэша, произведенные экземпляром приложения на одном из узлов, на все остальные узлы. Для этого в качестве прослойки между приложением и memcached прекрасно подходит mcrouter — маршрутизатор для масштабирования memcached-инсталляций. Мы уже даже писали о нем статью.
Добавляем в кластер mcrouter
Чтобы ускорить чтение данных из кэша, mcrouter тоже нужно запустить как DaemonSet. Так mcrouter будет «знать», какой из экземпляров memcached — ближайший, т. е. запущен на его узле. Для этого mcrouter можно поместить sidecar-контейнером в Pod’ы с memcached. Тогда ближайший memcached для mcrouter’a будет находиться по адресу 127.0.0.1.Но чтобы повысить отказоустойчивость, лучше выделить mcrouter в отдельный DaemonSet и вынести memcached и mcrouter в hostNetwork. При таком разделении любые проблемы с каким-либо экземпляром memcached не повлияют на доступность кэша для приложения. Перевыкат как для memcached, так и для mcrouter можно выполнять раздельно, что повышает отказоустойчивость всей системы при таких операциях.
Чтобы выделить memcached в hostNetwork, добавим в манифест: hostNetwork: true.
Также добавим переменную окружения с IP-адресом узла, на котором запущен Pod, в контейнер с memcached:
env:
- name: HOST_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
И модифицируем команду запуска memcached, чтобы порт был открыт только на внутреннем IP кластера:
command:
- /bin/bash
- -c
- --
- memcached --listen=$HOST_IP --port=30213 --memory-limit=2048 -o modern v --conn-limit=4096 -u memcache
Аналогично опишем DaemonSet mcrouter’a, Pod’ы которого также должны запускаться в hostNetwork:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: mcrouter
labels:
app: mcrouter
spec:
selector:
matchLabels:
app: mcrouter
template:
metadata:
labels:
app: mcrouter
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: node-role.kubernetes.io/node
operator: Exists
hostNetwork: true
imagePullSecrets:
- name: "registrysecret"
containers:
- name: mcrouter
image: {{ .Values.werf.image.mcrouter }}
command:
- /bin/bash
- -c
- --
- mcrouter --listen-addresses=$HOST_IP --port=31213 --config-file=/mnt/config/config.json --stats-root=/mnt/config/
volumeMounts:
- name: config
mountPath: /mnt/config
ports:
- name: mcr-production
containerPort: 30213
livenessProbe:
tcpSocket:
port: mcr-production
initialDelaySeconds: 30
timeoutSeconds: 5
readinessProbe:
tcpSocket:
port: mcr-production
initialDelaySeconds: 5
timeoutSeconds: 1
resources:
requests:
cpu: 300m
memory: 100Mi
limits:
memory: 100Mi
env:
- name: HOST_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
volumes:
- configMap:
name: mcrouter
name: mcrouter
- name: config
emptyDir: {}
Поскольку mcrouter тоже запущен в hostNetwork, для него также сделано ограничение, чтобы порт открывался только на внутреннем IP узлов.
Вариант сборки mcrouter, как мы это делаем с помощью werf (не составит труда переписать на обычный Dockerfile, если такая необходимость есть):
image: mcrouter
from: ubuntu:18.04
mount:
- from: tmp_dir
to: /var/lib/apt/lists
ansible:
beforeInstall:
- name: Install prerequisites
apt:
name:
- apt-transport-https
- apt-utils
- dnsutils
- gnupg
- tzdata
- locales
update_cache: yes
- name: Add mcrouter APT key
apt_key:
url: https://facebook.github.io/mcrouter/debrepo/bionic/PUBLIC.KEY
- name: Add mcrouter Repo
apt_repository:
repo: deb https://facebook.github.io/mcrouter/debrepo/bionic bionic contrib
filename: mcrouter
update_cache: yes
- name: Set timezone
timezone:
name: "Europe/Moscow"
- name: Ensure a locale exists
locale_gen:
name: en_US.UTF-8
state: present
install:
- name: Install mcrouter
apt:
name:
- mcrouter
И самое интересное — это конфигурационный файл mcrouter. Он должен генерироваться на лету, при запуске Pod’а на конкретном узле, чтобы подставить адрес «своего» узла как приоритетный для чтения. Для этого необходим init-контейнер в Pod’е с mcrouter’ом, который генерирует конфигурационный файл и подкладывает его в общий volume в emptyDir:
initContainers:
- name: init
image: {{ .Values.werf.image.mcrouter }}
command:
- /bin/bash
- -c
- /mnt/config/config_generator.sh /mnt/config/config.json
volumeMounts:
- name: mcrouter
mountPath: /mnt/config/config_generator.sh
subPath: config_generator.sh
- name: config
mountPath: /mnt/config
env:
- name: HOST_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
Вот так может выглядеть сам генератор конфигурационного файла, который выполняется в init-контейнере:
apiVersion: v1
kind: ConfigMap
metadata:
name: mcrouter
data:
config_generator.sh: |
#!/bin/bash
set -e
set -o pipefail
config_path=$1;
if [ -z "${config_path}" ]; then echo "config_path isn't specified"; exit 1; fi
function join_by { local d=$1; shift; local f=$1; shift; printf %s "$f" "${@/#/$d}"; }
mapfile -t ips < <( host mc.production.svc.cluster.local 10.222.0.10 | grep mc.production.svc.cluster.local | awk '{ print $4; }' | sort | grep -v $HOST_IP )
delimiter=':30213","'
servers='"'$(join_by $delimiter $HOST_IP "${ips[@]}")':30213"'
cat <<< '{
"pools": {
"A": {
"servers": [
'$servers'
]
}
},
"route": {
"type": "OperationSelectorRoute",
"operation_policies": {
"add": "AllSyncRoute|Pool|A",
"delete": "AllSyncRoute|Pool|A",
"get": "FailoverRoute|Pool|A",
"set": "AllSyncRoute|Pool|A"
}
}
}
' > $config_path
Скрипт обращается к внутреннему DNS в K8s-кластере, получает все IP-адреса для Pod’ов memcached и формирует список адресов. Первый в списке — IP-адрес того узла, на котором запущен наш экземпляр mcrouter.
Обратите внимание! Для того, чтобы при обращении к DNS были получены адреса Pod’ов, в приведенном выше манифесте Service для memcached указана спецификация clusterIP: None.
Результат работы скрипта:
cat /mnt/config/config.json
{
"pools": {
"A": {
"servers": [
"192.168.100.33:30213","192.168.100.14:30213","192.168.100.15:30213","192.168.100.16:30213","192.168.100.21:30213","192.168.100.22:30213","192.168.100.23:30213","192.168.100.34:30213"
]
}
},
"route": {
"type": "OperationSelectorRoute",
"operation_policies": {
"add": "AllSyncRoute|Pool|A",
"delete": "AllSyncRoute|Pool|A",
"get": "FailoverRoute|Pool|A",
"set": "AllSyncRoute|Pool|A"
}
}
}
Так мы обеспечиваем синхронизацию записи изменений на все экземпляры memcached и приоритетное чтение со «своего» узла.
NB. Если строгого требования к когерентности кэша нет, то для большей скорости работы и меньшей чувствительности к нестабильности кластера в целом рекомендуется вместо AllSyncRoute использовать дескриптор маршрута AllMajorityRoute или даже AllFastestRoute.
Поправка на ветер
Однако есть еще одна проблема: кластеры, как правило, не статичные — число рабочих узлов в кластере может меняться. При увеличении числа узлов в кластере будет нарушена когерентность кэша:- Появятся новые экземпляры memcached и mcrouter.
- Новые экземпляры mcrouter будут писать в старые экземпляры memcached. А старые экземпляры mcrouter о новых экземплярах memcached не узнают.
Вариант решения: в Pod’е с mcrouter’ом сделать sidecar-контейнер с cron’ом, по которому бы делалась проверка списка узлов и применялись изменения.
Конфигурация sidecar’а:
- name: cron
image: {{ .Values.werf.image.cron }}
command:
- /usr/local/bin/dumb-init
- /bin/sh
- -c
- /usr/local/bin/supercronic -json /app/crontab
volumeMounts:
- name: mcrouter
mountPath: /mnt/config/config_generator.sh
subPath: config_generator.sh
- name: mcrouter
mountPath: /mnt/config/check_nodes.sh
subPath: check_nodes.sh
- name: mcrouter
mountPath: /app/crontab
subPath: crontab
- name: config
mountPath: /mnt/config
resources:
limits:
memory: 64Mi
requests:
memory: 64Mi
cpu: 5m
env:
- name: HOST_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
Скрипты, работающие в этом cron’е, вызывают тот же самый config_generator.sh, который используется в init-контейнере:
crontab: |
# Check nodes in cluster
* * * * * * * /mnt/config/check_nodes.sh /mnt/config/config.json
check_nodes.sh: |
#!/usr/bin/env bash
set -e
config_path=$1;
if [ -z "${config_path}" ]; then echo "config_path isn't specified"; exit 1; fi
check_path="${config_path}.check"
checksum1=$(md5sum $config_path | awk '{print $1;}')
/mnt/config/config_generator.sh $check_path
checksum2=$(md5sum $check_path | awk '{print $1;}')
if [[ $checksum1 == $checksum2 ]]; then
echo "No changes for nodes."
exit 0;
else
echo "Node list was changed."
mv $check_path $config_path
echo "mcrouter is reconfigured."
fi
Раз в секунду вызывается скрипт, который генерирует конфигурационный файл для mcrouter. При изменении контрольной суммы конфигурационного файла обновленный файл подкладывается mcrouter’у через общий между контейнерами каталог в emptyDir. Дополнительно заставлять mcrouter обновлять конфигурацию не требуется, т. к. он сам перечитывает свой конфигурационный файл раз в секунду.
Теперь осталось только в Pod’е с приложением указать IP-адрес самого узла — в переменной окружения, в которой указывается адрес memcached. А в качестве порта memcached указать порт mcrouter’a:
env:
- name: MEMCACHED_HOST
valueFrom:
fieldRef:
fieldPath: status.hostIP
- name: MEMCACHED_PORT
value: 31213
Результат
В итоге цель проекта была достигнута: удалось заметно ускорить работу приложения. По данным New Relic, время взаимодействия приложения с memcached в процессе обработки пользовательского запроса сократилось с 70-80 мс до ~20 мс.Состояние до оптимизации:
После оптимизации:
Решение применяется в production примерно полгода, и за это время подводных камней не всплыло.
Итоговые листинги, упомянутые в статье (Helm-чарты и werf.yaml), доступны в репозитории flant/examples.
Готовим высокодоступный memcached с mcrouter в Kubernetes
В одном из проектов мне пришлось столкнуться с классической ситуацией: нагрузка со стороны приложения на реляционную БД была чрезвычайно высока из-за большого RPS (requests per second). Однако...
habr.com