Изпълнение на ProxySQL като помощен контейнер на Kubernetes

ProxySQL обикновено се намира между нивата на приложението и базата данни, в така нареченото ниво на обратен прокси. Когато контейнерите на вашите приложения са организирани и управлявани от Kubernetes, може да искате да използвате ProxySQL пред сървърите на вашите бази данни.

В тази публикация ще ви покажем как да стартирате ProxySQL на Kubernetes като помощен контейнер в pod. Ще използваме Wordpress като примерно приложение. Услугата за данни се предоставя от нашата MySQL репликация с два възела, разгърната с помощта на ClusterControl и разположена извън мрежата на Kubernetes в гола метална инфраструктура, както е илюстрирано на следната диаграма:

ProxySQL Docker изображение

В този пример ще използваме ProxySQL Docker изображение, поддържано от Severalnines, общо публично изображение, създадено за многоцелева употреба. Изображението се предлага без входен скрипт и поддържа Galera Cluster (в допълнение към вградената поддръжка за MySQL репликация), където се изисква допълнителен скрипт за целите на проверката на здравето.

По принцип, за да стартирате ProxySQL контейнер, просто изпълнете следната команда:

$ docker run -d -v /path/to/proxysql.cnf:/etc/proxysql.cnf severalnines/proxysql

Това изображение ви препоръчва да свържете конфигурационен файл на ProxySQL към точката на монтиране, /etc/proxysql.cnf, въпреки че можете да пропуснете това и да го конфигурирате по-късно, като използвате ProxySQL Admin конзолата. Примерни конфигурации са предоставени на страницата на Docker Hub или страницата на Github.

ProxySQL на Kubernetes

Проектирането на архитектурата на ProxySQL е субективна тема и силно зависи от разположението на контейнерите на приложението и базата данни, както и от ролята на самия ProxySQL. ProxySQL не само маршрутизира заявки, но може да се използва и за пренаписване и кеширане на заявки. Ефективните посещения в кеша може да изискват персонализирана конфигурация, пригодена специално за работното натоварване на базата данни на приложението.

В идеалния случай можем да конфигурираме ProxySQL да се управлява от Kubernetes с две конфигурации:

ProxySQL като услуга на Kubernetes (централизирано внедряване).
ProxySQL като помощен контейнер в модул (разпределено внедряване).

Първият вариант е доста ясен, където създаваме ProxySQL pod и прикачваме услуга Kubernetes към него. След това приложенията ще се свържат с услугата ProxySQL чрез мрежа на конфигурираните портове. По подразбиране е 6033 за MySQL порт с балансирано натоварване и 6032 за порт за администриране на ProxySQL. Това внедряване ще бъде разгледано в предстоящата публикация в блога.

Вторият вариант е малко по-различен. Kubernetes има концепция, наречена "pod". Можете да имате един или повече контейнери на шушулка, те са относително тясно свързани. Съдържанието на модула винаги е съвместно разположено и съвместно насрочено и се изпълнява в споделен контекст. Pod е най-малката управлявана контейнерна единица в Kubernetes.

И двете разгръщания могат да бъдат разграничени лесно, като погледнете следната диаграма:

Основната причина, поради която модулите могат да имат множество контейнери, е да поддържат помощни приложения, които подпомагат основно приложение. Типични примери за помощни приложения са изтеглящи данни, избутващи данни и прокси сървъри. Помощните и основните приложения често трябва да комуникират помежду си. Обикновено това се прави чрез споделена файлова система, както е показано в това упражнение, или чрез loopback мрежов интерфейс, localhost. Пример за този модел е уеб сървър заедно с помощна програма, която запитва Git хранилище за нови актуализации.

Тази публикация в блога ще обхване втората конфигурация - стартиране на ProxySQL като помощен контейнер в под.

ProxySQL като помощник в под

В тази настройка стартираме ProxySQL като помощен контейнер към нашия Wordpress контейнер. Следната диаграма илюстрира нашата архитектура на високо ниво:

В тази настройка контейнерът ProxySQL е тясно свързан с контейнера на Wordpress и го нарекохме като модул „блог“. Ако се случи разсрочване, например работният възел на Kubernetes изпадне, тези два контейнера винаги ще бъдат пренасрочени заедно като една логическа единица на следващия наличен хост. За да запазим съдържанието на контейнерите на приложенията постоянно в множество възли, трябва да използваме клъстерна или отдалечена файлова система, която в този случай е NFS.

Ролята на ProxySQL е да предостави слой за абстракция на база данни към контейнера на приложението. Тъй като изпълняваме MySQL репликация с два възела като услуга за бекенд база данни, разделянето на четене и запис е жизненоважно за максимизиране на потреблението на ресурси и на двата MySQL сървъра. ProxySQL се отличава с това и изисква минимални или никакви промени в приложението.

Има редица други предимства, работещи с ProxySQL в тази настройка:

Приближете възможността за кеширане на заявки най-близо до слоя на приложението, работещ в Kubernetes.
Сигурна реализация чрез свързване чрез ProxySQL UNIX файл на сокет. Това е като тръба, която сървърът и клиентите могат да използват за свързване и обмен на заявки и данни.
Разпределено ниво на обратен прокси с архитектура за нищо не споделя.
По-малко разходи за мрежата поради внедряването на „пропускане на мрежа“.
Подход за внедряване без състояние чрез използване на Kubernetes ConfigMaps.

Подготовка на базата данни

Създайте wordpress базата данни и потребителя на главния и задайте с правилни привилегии:

mysql-master> CREATE DATABASE wordpress;
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql-master> GRANT ALL PRIVILEGES ON wordpress.* TO [email protected]'%';

Също така, създайте потребителя за наблюдение на ProxySQL:

mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'proxysqlpassw0rd';

След това презаредете таблицата за предоставяне:

mysql-master> FLUSH PRIVILEGES;

Подготовка на капсулата

Сега копирайте и поставете следните редове във файл, наречен blog-deployment.yml на хоста, където е конфигуриран kubectl:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: blog
  labels:
    app: blog
spec:
  replicas: 1
  selector:
    matchLabels:
      app: blog
      tier: frontend
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: blog
        tier: frontend
    spec:

      restartPolicy: Always

      containers:
      - image: wordpress:4.9-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: localhost:/tmp/proxysql.sock
        - name: WORDPRESS_DB_USER
          value: wordpress
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
        - name: shared-data
          mountPath: /tmp

      - image: severalnines/proxysql
        name: proxysql
        volumeMounts:
        - name: proxysql-config
          mountPath: /etc/proxysql.cnf
          subPath: proxysql.cnf
        - name: shared-data
          mountPath: /tmp

      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim
      - name: proxysql-config
        configMap:
          name: proxysql-configmap
      - name: shared-data
        emptyDir: {}

YAML файлът има много редове и нека разгледаме само интересната част. Първият раздел:

apiVersion: apps/v1
kind: Deployment

Първият ред е apiVersion. Нашият Kubernetes клъстер работи на v1.12, така че трябва да се обърнем към документацията на API на Kubernetes v1.12 и да следваме декларацията на ресурсите според този API. Следващият е видът, който казва какъв тип ресурс искаме да разположим. Разгръщане, услуга, ReplicaSet, DaemonSet, PersistentVolume са някои от примерите.

Следващият важен раздел е разделът "контейнери". Тук ние дефинираме всички контейнери, които бихме искали да изпълняваме заедно в този модул. Първата част е контейнерът на Wordpress:

      - image: wordpress:4.9-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: localhost:/tmp/proxysql.sock
        - name: WORDPRESS_DB_USER
          value: wordpress
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
        - name: shared-data
          mountPath: /tmp

В този раздел казваме на Kubernetes да внедри Wordpress 4.9 с помощта на уеб сървър на Apache и дадохме на контейнера името "wordpress". Също така искаме Kubernetes да предава редица променливи на средата:

WORDPRESS_DB_HOST - Хостът на базата данни. Тъй като нашият ProxySQL контейнер се намира в същия Pod с контейнера Wordpress, по-сигурно е вместо това да използвате ProxySQL файл на сокет. Форматът за използване на сокет файл в Wordpress е "localhost:{път към файла на сокета}". По подразбиране се намира в директорията /tmp на контейнера ProxySQL. Този /tmp път се споделя между контейнерите на Wordpress и ProxySQL чрез използване на volumeMounts "споделени данни", както е показано по-долу. И двата контейнера трябва да монтират този том, за да споделят едно и също съдържание в директорията /tmp.
WORDPRESS_DB_USER - Посочете потребителя на базата данни на WordPress.
WORDPRESS_DB_PASSWORD - Паролата за WORDPRESS_DB_USER . Тъй като не искаме да разкриваме паролата в този файл, можем да я скрием с помощта на Kubernetes Secrets. Тук инструктираме Kubernetes да прочете тайния ресурс "mysql-pass". Тайните трябва да бъдат създадени предварително преди разполагането на модула, както е обяснено по-долу.

Също така искаме да публикуваме порт 80 на контейнера за крайния потребител. Съдържанието на Wordpress, съхранявано в /var/www/html в контейнера, ще бъде монтирано в нашето постоянно хранилище, работещо на NFS.

След това дефинираме контейнера ProxySQL:

      - image: severalnines/proxysql:1.4.12
        name: proxysql
        volumeMounts:
        - name: proxysql-config
          mountPath: /etc/proxysql.cnf
          subPath: proxysql.cnf
        - name: shared-data
          mountPath: /tmp
        ports:
        - containerPort: 6033
          name: proxysql

В горния раздел казваме на Kubernetes да разположи ProxySQL с помощта на severalnines/proxysql версия на изображението 1.4.12. Също така искаме Kubernetes да монтира нашия персонализиран, предварително конфигуриран конфигурационен файл и да го съпостави с /etc/proxysql.cnf вътре в контейнера. Ще има том, наречен "споделени данни", който се преобразува в директория /tmp за споделяне с изображението на Wordpress - временна директория, която споделя живота на модула. Това позволява ProxySQL сокетният файл (/tmp/proxysql.sock) да се използва от контейнера на Wordpress при свързване към базата данни, заобикаляйки TCP/IP мрежата.

Последната част е разделът "обеми":

      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wp-pv-claim
      - name: proxysql-config
        configMap:
          name: proxysql-configmap
      - name: shared-data
        emptyDir: {}

Kubernetes ще трябва да създаде три тома за този модул:

wordpress-persistent-storage - Използвайте PersistentVolumeClaim ресурс за картографиране на експортиране на NFS в контейнера за постоянно съхранение на данни за съдържание на Wordpress.
proxysql-config - Използвайте ConfigMap ресурс за картографиране на конфигурационния файл на ProxySQL.
споделени-данни – Използвайте emptyDir ресурс за монтиране на споделена директория за нашите контейнери в Pod. emptyDir ресурсът е временна директория, която споделя живота на модула.

Следователно, въз основа на нашата YAML дефиниция по-горе, трябва да подготвим редица ресурси на Kubernetes, преди да можем да започнем да разгръщаме модула „блог“:

Постоянен обем и PersistentVolumeClaim - За да съхраняваме уеб съдържанието на нашето приложение Wordpress, така че когато модулът се пренасрочи към друг работен възел, няма да загубим последните промени.
Тайни - За да скриете потребителската парола на базата данни на Wordpress във файла YAML.
ConfigMap - За да съпоставите конфигурационния файл с ProxySQL контейнера, така че когато бъде пренасрочен на друг възел, Kubernetes може автоматично да го монтира отново.

Неколкократни MySQL на Docker:Как да контейнеризирате вашата база данни Открийте всичко, което трябва да разберете, когато обмисляте да стартирате услуга MySQL върху виртуализацията на Docker контейнер. Изтеглете Бялата книга

PersistentVolume и PersistentVolumeClaim

Доброто постоянно съхранение за Kubernetes трябва да бъде достъпно за всички възли на Kubernetes в клъстера. В името на тази публикация в блога използвахме NFS като доставчик на PersistentVolume (PV), защото е лесен и поддържан от кутията. NFS сървърът се намира някъде извън нашата Kubernetes мрежа и ние сме го конфигурирали да разрешава всички възли на Kubernetes със следния ред вътре в /etc/exports:

/nfs    192.168.55.*(rw,sync,no_root_squash,no_all_squash)

Обърнете внимание, че клиентският пакет на NFS трябва да бъде инсталиран на всички възли на Kubernetes. В противен случай Kubernetes няма да може да монтира правилно NFS. На всички възли:

$ sudo apt-install nfs-common #Ubuntu/Debian
$ yum install nfs-utils #RHEL/CentOS

Също така се уверете, че на NFS сървъра съществува целевата директория:

(nfs-server)$ mkdir /nfs/kubernetes/wordpress

След това създайте файл, наречен wordpress-pv-pvc.yml и добавете следните редове:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: wp-pv
  labels:
    app: blog
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 3Gi
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /nfs/kubernetes/wordpress
    server: 192.168.55.200
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: wp-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi
  selector:
    matchLabels:
      app: blog
      tier: frontend

В горната дефиниция бихме искали Kubernetes да задели 3GB обемно пространство на NFS сървъра за нашия Wordpress контейнер. Обърнете внимание за производствената употреба, NFS трябва да бъде конфигуриран с автоматичен доставчик и клас за съхранение.

Създайте PV и PVC ресурси:

$ kubectl create -f wordpress-pv-pvc.yml

Проверете дали тези ресурси са създадени и състоянието трябва да е „Обвързано“:

$ kubectl get pv,pvc
NAME                     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
persistentvolume/wp-pv   3Gi        RWO            Recycle          Bound    default/wp-pvc                           22h

NAME                           STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/wp-pvc   Bound    wp-pv    3Gi        RWO                           22h

Тайни

Първият е да създадете тайна, която да се използва от контейнера на Wordpress за WORDPRESS_DB_PASSWORD променлива на средата. Причината е просто, защото не искаме да разкриваме паролата в ясен текст във файла YAML.

Създайте таен ресурс, наречен mysql-pass, и подайте съответно паролата:

$ kubectl create secret generic mysql-pass --from-literal=password=passw0rd

Проверете дали нашата тайна е създадена:

$ kubectl get secrets mysql-pass
NAME         TYPE     DATA   AGE
mysql-pass   Opaque   1      7h12m

ConfigMap

Също така трябва да създадем ресурс ConfigMap за нашия ProxySQL контейнер. Файлът Kubernetes ConfigMap съдържа двойки ключ-стойност конфигурационни данни, които могат да се консумират в модули или да се използват за съхраняване на конфигурационни данни. ConfigMaps ви позволяват да отделяте конфигурационните артефакти от съдържанието на изображението, за да поддържате преносими приложения в контейнери.

Тъй като нашият сървър на база данни вече работи на голи сървъри със статично име на хост и IP адрес плюс потребителско име и парола за статичен мониторинг, в този случай на използване файлът ConfigMap ще съхранява предварително конфигурирана информация за конфигурацията за услугата ProxySQL, която искаме да използваме.

Първо създайте текстов файл, наречен proxysql.cnf, и добавете следните редове:

datadir="/var/lib/proxysql"
admin_variables=
{
        admin_credentials="admin:adminpassw0rd"
        mysql_ifaces="0.0.0.0:6032"
        refresh_interval=2000
}
mysql_variables=
{
        threads=4
        max_connections=2048
        default_query_delay=0
        default_query_timeout=36000000
        have_compress=true
        poll_timeout=2000
        interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
        default_schema="information_schema"
        stacksize=1048576
        server_version="5.1.30"
        connect_timeout_server=10000
        monitor_history=60000
        monitor_connect_interval=200000
        monitor_ping_interval=200000
        ping_interval_server_msec=10000
        ping_timeout_server=200
        commands_stats=true
        sessions_sort=true
        monitor_username="proxysql"
        monitor_password="proxysqlpassw0rd"
}
mysql_servers =
(
        { address="192.168.55.171" , port=3306 , hostgroup=10, max_connections=100 },
        { address="192.168.55.172" , port=3306 , hostgroup=10, max_connections=100 },
        { address="192.168.55.171" , port=3306 , hostgroup=20, max_connections=100 },
        { address="192.168.55.172" , port=3306 , hostgroup=20, max_connections=100 }
)
mysql_users =
(
        { username = "wordpress" , password = "passw0rd" , default_hostgroup = 10 , active = 1 }
)
mysql_query_rules =
(
        {
                rule_id=100
                active=1
                match_pattern="^SELECT .* FOR UPDATE"
                destination_hostgroup=10
                apply=1
        },
        {
                rule_id=200
                active=1
                match_pattern="^SELECT .*"
                destination_hostgroup=20
                apply=1
        },
        {
                rule_id=300
                active=1
                match_pattern=".*"
                destination_hostgroup=10
                apply=1
        }
)
mysql_replication_hostgroups =
(
        { writer_hostgroup=10, reader_hostgroup=20, comment="MySQL Replication 5.7" }
)

Обърнете допълнително внимание на секциите "mysql_servers" и "mysql_users", където може да се наложи да промените стойностите, за да отговарят на настройката на клъстера на вашата база данни. В този случай имаме два сървъра на бази данни, работещи в MySQL репликация, както е обобщено в следната екранна снимка на топологията, взета от ClusterControl:

Всички записи трябва да отидат до главния възел, докато четенията се препращат към хостгрупа 20, както е дефинирано в раздела "mysql_query_rules". Това е основата на разделянето на четене/запис и ние искаме да ги използваме изцяло.

След това импортирайте конфигурационния файл в ConfigMap:

$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf
configmap/proxysql-configmap created

Проверете дали ConfigMap е зареден в Kubernetes:

$ kubectl get configmap
NAME                 DATA   AGE
proxysql-configmap   1      45s

Разгръщане на Pod

Сега трябва да сме готови да разположим модула на блога. Изпратете заданието за внедряване на Kubernetes:

$ kubectl create -f blog-deployment.yml

Проверете състоянието на капсулата:

$ kubectl get pods
NAME                           READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-t4cb7          2/2     Running             0          100s

Той трябва да показва 2/2 под колоната ГОТОВ, което показва, че има два контейнера, работещи вътре в капсулата. Използвайте флага за опция -c, за да проверите контейнерите на Wordpress и ProxySQL в модула на блога:

$ kubectl logs blog-54755cbcb5-t4cb7 -c wordpress
$ kubectl logs blog-54755cbcb5-t4cb7 -c proxysql

От дневника на контейнера ProxySQL трябва да видите следните редове:

2018-10-20 08:57:14 [INFO] Dumping current MySQL Servers structures for hostgroup ALL
HID: 10 , address: 192.168.55.171 , port: 3306 , weight: 1 , status: ONLINE , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:
HID: 10 , address: 192.168.55.172 , port: 3306 , weight: 1 , status: OFFLINE_HARD , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:
HID: 20 , address: 192.168.55.171 , port: 3306 , weight: 1 , status: ONLINE , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:
HID: 20 , address: 192.168.55.172 , port: 3306 , weight: 1 , status: ONLINE , max_connections: 100 , max_replication_lag: 0 , use_ssl: 0 , max_latency_ms: 0 , comment:

HID 10 (хост група за запис) трябва да има само един ОНЛАЙН възел (указващ един главен), а другият хост трябва да е поне в състояние OFFLINE_HARD. За HID 20 се очаква да бъде ОНЛАЙН за всички възли (което показва множество прочетени реплики).

За да получите обобщение на внедряването, използвайте флага за описание:

$ kubectl describe deployments blog

Нашият блог вече работи, но не можем да получим достъп до него извън мрежата на Kubernetes, без да конфигурираме услугата, както е обяснено в следващия раздел.

Създаване на услугата за блог

Последната стъпка е да създадете прикачена услуга към нашия модул. Това, за да се гарантира, че нашият блог под Wordpress е достъпен от външния свят. Създайте файл, наречен blog-svc.yml и поставете следния ред:

apiVersion: v1
kind: Service
metadata:
  name: blog
  labels:
    app: blog
    tier: frontend
spec:
  type: NodePort
  ports:
  - name: blog
    nodePort: 30080
    port: 80
  selector:
    app: blog
    tier: frontend

Създайте услугата:

$ kubectl create -f blog-svc.yml

Проверете дали услугата е създадена правилно:

[email protected]:~/proxysql-blog# kubectl get svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
blog         NodePort    10.96.140.37   <none>        80:30080/TCP   26s
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP        43h

Порт 80, публикуван от модула на блога, вече е картографиран към външния свят чрез порт 30080. Имаме достъп до нашата публикация в блога на адрес http://{any_kubernetes_host}:30080/ и трябва да бъдем пренасочени към страницата за инсталиране на Wordpress. Ако продължим с инсталацията, тя ще пропусне частта за връзка с базата данни и ще покаже директно тази страница:

Това показва, че конфигурацията на MySQL и ProxySQL е правилно конфигурирана във файла wp-config.php. В противен случай ще бъдете пренасочени към страницата за конфигурация на базата данни.

Внедряването ни вече е завършено.

Управление на ProxySQL контейнер в Pod

Очаква се отказът и възстановяването да се обработват автоматично от Kubernetes. Например, ако работникът на Kubernetes падне, модулът ще бъде пресъздаден в следващия наличен възел след --pod-eviction-timeout (по подразбиране е 5 минути). Ако контейнерът се срине или бъде убит, Kubernetes ще го замени почти мигновено.

Очаква се някои общи задачи за управление да бъдат различни, когато се изпълняват в Kubernetes, както е показано в следващите раздели.

Увеличаване и намаляване на мащаба

В горната конфигурация разгръщахме една реплика в нашето внедряване. За да увеличите мащаба, просто променете spec.replicas стойност съответно, като използвате командата за редактиране на kubectl:

$ kubectl edit deployment blog

Той ще отвори дефиницията за внедряване в текстов файл по подразбиране и просто ще промени spec.replicas стойност на нещо по-високо, например "реплика:3". След това запазете файла и незабавно проверете състоянието на пускането, като използвате следната команда:

$ kubectl rollout status deployment blog
Waiting for deployment "blog" rollout to finish: 1 of 3 updated replicas are available...
Waiting for deployment "blog" rollout to finish: 2 of 3 updated replicas are available...
deployment "blog" successfully rolled out

В този момент имаме три модула за блогове (Wordpress + ProxySQL), работещи едновременно в Kubernetes:

$ kubectl get pods
NAME                             READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-6fnqn            2/2     Running             0          11m
blog-54755cbcb5-cwpdj            2/2     Running             0          11m
blog-54755cbcb5-jxtvc            2/2     Running             0          22m

В този момент нашата архитектура изглежда така:

Обърнете внимание, че може да изисква повече персонализиране от настоящата ни конфигурация, за да работи Wordpress гладко в хоризонтално мащабирана производствена среда (помислете за статичното съдържание, управлението на сесиите и други). Това всъщност са извън обхвата на тази публикация в блога.

Процедурите за намаляване на мащаба са подобни.

Управление на конфигурацията

Управлението на конфигурацията е важно в ProxySQL. Това е мястото, където се случва магията, когато можете да дефинирате свой собствен набор от правила за заявка, за да извършвате кеширане на заявки, защитна стена и пренаписване. Противно на обичайната практика, при която ProxySQL ще бъде конфигуриран през конзолата на администратора и ще бъде насочен към постоянство чрез използване на „SAVE.. TO DISK“, ние ще се придържаме към конфигурационни файлове само за да направим нещата по-преносими в Kubernetes. Това е причината да използваме ConfigMaps.

Тъй като разчитаме на нашата централизирана конфигурация, съхранявана от Kubernetes ConfigMaps, има няколко начина за извършване на промени в конфигурацията. Първо, с помощта на командата за редактиране kubectl:

$ kubectl edit configmap proxysql-configmap

Той ще отвори конфигурацията в текстов редактор по подразбиране и можете директно да правите промени в нея и да запишете текстовия файл, след като го направите. В противен случай пресъздаването на конфигурационните карти също трябва да направи:

$ vi proxysql.cnf # edit the configuration first
$ kubectl delete configmap proxysql-configmap
$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf

След като конфигурацията бъде вкарана в ConfigMap, рестартирайте модула или контейнера, както е показано в раздела за контрол на услугите. Конфигурирането на контейнера чрез ProxySQL администраторски интерфейс (порт 6032) няма да го направи постоянен след разсрочване на модула от Kubernetes.

Управление на услугите

Тъй като двата контейнера вътре в модула са плътно свързани, най-добрият начин да приложите промените в конфигурацията на ProxySQL е да принудите Kubernetes да извърши подмяна на модула. Помислете, че сега имаме три модула за блогове, след като увеличихме мащаба:

$ kubectl get pods
NAME                             READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-6fnqn            2/2     Running             0          31m
blog-54755cbcb5-cwpdj            2/2     Running             0          31m
blog-54755cbcb5-jxtvc            2/2     Running             1          22m

Използвайте следната команда, за да замените една по една капсула:

$ kubectl get pod blog-54755cbcb5-6fnqn -n default -o yaml | kubectl replace --force -f -
pod "blog-54755cbcb5-6fnqn" deleted
pod/blog-54755cbcb5-6fnqn

След това проверете със следното:

$ kubectl get pods
NAME                             READY   STATUS              RESTARTS   AGE
blog-54755cbcb5-6fnqn            2/2     Running             0          31m
blog-54755cbcb5-cwpdj            2/2     Running             0          31m
blog-54755cbcb5-qs6jm            2/2     Running             1          2m26s

Ще забележите, че последният модул е рестартиран, като погледнете колоните AGE и RESTART, той излезе с различно име на модула. Повторете същите стъпки за останалите шушулки. В противен случай можете също да използвате командата "docker kill", за да убиете ръчно контейнера ProxySQL в работния възел на Kubernetes. Например:

(kube-worker)$ docker kill $(docker ps | grep -i proxysql_blog | awk {'print $1'})

След това Kubernetes ще замени убития ProxySQL контейнер с нов.

Наблюдение

Използвайте командата kubectl exec, за да изпълните SQL оператор чрез mysql клиент. Например, за да наблюдавате усвояването на заявката:

$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032
mysql> SELECT * FROM stats_mysql_query_digest;

Или с едноредово:

$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032 -e 'SELECT * FROM stats_mysql_query_digest'

Чрез промяна на SQL израза можете да наблюдавате други компоненти на ProxySQL или да изпълнявате каквито и да е административни задачи чрез тази администраторска конзола. Отново, той ще се запази само по време на живота на контейнера ProxySQL и няма да се запази, ако модулът бъде разсрочен.

Последни мисли

ProxySQL има ключова роля, ако искате да мащабирате контейнерите на приложенията си и да имате интелигентен начин за достъп до бекенда на разпределена база данни. Има няколко начина за внедряване на ProxySQL в Kubernetes, за да подкрепим растежа на нашето приложение, когато работим в мащаб. Тази публикация в блога обхваща само един от тях.

В предстояща публикация в блога ще разгледаме как да стартирате ProxySQL в централизиран подход, като го използвате като услуга на Kubernetes.