MariaDB
 sql >> база данни >  >> RDS >> MariaDB

Изпълняване на ProxySQL като Kubernetes Service

Когато се изпълняват клъстери на разпределени бази данни, е доста обичайно да ги изправите с балансьори на натоварване. Предимствата са ясни - балансиране на натоварването, преодоляване на връзката и отделяне на нивото на приложението от основните топологии на базата данни. За по-интелигентно балансиране на натоварването, прокси, работещ с база данни, като ProxySQL или MaxScale, би бил правилният начин. В предишния ни блог ви показахме как да стартирате ProxySQL като помощен контейнер в Kubernetes. В тази публикация в блога ще ви покажем как да разположите ProxySQL като услуга на Kubernetes. Ще използваме Wordpress като примерно приложение и бекенда на базата данни работи на MySQL репликация с два възела, разгърната с помощта на ClusterControl. Следната диаграма илюстрира нашата инфраструктура:

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

ProxySQL на Kubernetes

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

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

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

Тази публикация в блога ще обхване първата конфигурация - стартиране на ProxySQL като услуга на Kubernetes. Втората конфигурация вече е разгледана тук. За разлика от подхода на помощния контейнер, изпълняването като услуга кара ProxySQL модулите да живеят независимо от приложенията и могат лесно да бъдат мащабирани и групирани заедно с помощта на Kubernetes ConfigMap. Това определено е различен подход за клъстериране от поддръжката на собствена клъстеризация на ProxySQL, която разчита на контролната сума на конфигурацията в екземплярите на ProxySQL (известни като proxysql_servers). Вижте тази публикация в блога, ако искате да научите за клъстерирането на ProxySQL, което става лесно с ClusterControl.

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

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

ProxySQL като услуга Kubernetes

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

В тази настройка ще разположим два модула и услуги - "wordpress" и "proxysql". Ще обединим декларацията за внедряване и услуга в един YAML файл за приложение и ще ги управляваме като едно цяло. За да запазим съдържанието на контейнерите на приложенията постоянно в множество възли, трябва да използваме клъстерна или отдалечена файлова система, която в този случай е NFS.

Внедряването на ProxySQL като услуга носи няколко добри неща в сравнение с подхода на помощния контейнер:

  • Използвайки подхода на Kubernetes ConfigMap, ProxySQL може да бъде групиран с неизменна конфигурация.
  • Kubernetes обработва възстановяването на ProxySQL и автоматично балансира връзките към екземплярите.
  • Единична крайна точка с реализация на виртуален IP адрес на Kubernetes, наречена ClusterIP.
  • Централизиран обратен прокси ниво с архитектура за нищо не споделя.
  • Може да се използва с външни приложения извън Kubernetes.

Ще започнем внедряването като две реплики за ProxySQL и три за Wordpress, за да демонстрираме работа в мащаб и възможности за балансиране на натоварването, които Kubernetes предлага.

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

Създайте 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;

ProxySQL Pod и дефиниция на услугата

Следващият е да подготвим внедряването на ProxySQL. Създайте файл, наречен proxysql-rs-svc.yml и добавете следните редове:

apiVersion: v1
kind: Deployment
metadata:
  name: proxysql
  labels:
    app: proxysql
spec:
  replicas: 2
  selector:
    matchLabels:
      app: proxysql
      tier: frontend
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: proxysql
        tier: frontend
    spec:
      restartPolicy: Always
      containers:
      - image: severalnines/proxysql:1.4.12
        name: proxysql
        volumeMounts:
        - name: proxysql-config
          mountPath: /etc/proxysql.cnf
          subPath: proxysql.cnf
        ports:
        - containerPort: 6033
          name: proxysql-mysql
        - containerPort: 6032
          name: proxysql-admin
      volumes:
      - name: proxysql-config
        configMap:
          name: proxysql-configmap
---
apiVersion: v1
kind: Service
metadata:
  name: proxysql
  labels:
    app: proxysql
    tier: frontend
spec:
  type: NodePort
  ports:
  - nodePort: 30033
    port: 6033
    name: proxysql-mysql
  - nodePort: 30032
    port: 6032
    name: proxysql-admin
  selector:
    app: proxysql
    tier: frontend

Нека видим какви са тези дефиниции. YAML се състои от два ресурса, комбинирани във файл, разделени с разделител "---". Първият ресурс е Deployment, който дефинираме следната спецификация:

spec:
  replicas: 2
  selector:
    matchLabels:
      app: proxysql
      tier: frontend
  strategy:
    type: RollingUpdate

Горното означава, че бихме искали да разположим две ProxySQL модули като ReplicaSet, който съответства на контейнери, етикетирани с "app=proxysql,tier=frontend". Стратегията за внедряване определя стратегията, използвана за замяна на стари модули с нови. При това внедряване избрахме RollingUpdate, което означава, че модулите ще бъдат актуализирани по начин на непрекъсната актуализация, една по една.

Следващата част е шаблонът на контейнера:

      - image: severalnines/proxysql:1.4.12
        name: proxysql
        volumeMounts:
        - name: proxysql-config
          mountPath: /etc/proxysql.cnf
          subPath: proxysql.cnf
        ports:
        - containerPort: 6033
          name: proxysql-mysql
        - containerPort: 6032
          name: proxysql-admin
      volumes:
      - name: proxysql-config
        configMap:
          name: proxysql-configmap

В spec.templates.spec.containers.* раздел, ние казваме на Kubernetes да разположи ProxySQL с помощта на severalnines/proxysql версия на изображението 1.4.12. Също така искаме Kubernetes да монтира нашия персонализиран, предварително конфигуриран конфигурационен файл и да го съпостави с /etc/proxysql.cnf вътре в контейнера. Работещите модули ще публикуват два порта - 6033 и 6032. Ние също така дефинираме секцията "обемове", където инструктираме Kubernetes да монтира ConfigMap като том вътре в модулите ProxySQL, който да бъде монтиран от volumeMounts.

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

apiVersion: v1
kind: Service
metadata:
  name: proxysql
  labels:
    app: proxysql
    tier: frontend
spec:
  type: NodePort
  ports:
  - nodePort: 30033
    port: 6033
    name: proxysql-mysql
  - nodePort: 30032
    port: 6032
    name: proxysql-admin
  selector:
    app: proxysql
    tier: frontend

В този случай искаме нашият ProxySQL да бъде достъпен от външната мрежа, така че типът NodePort е избраният тип. Това ще публикува nodePort на всички възли на Kubernetes в клъстера. Диапазонът от валидни портове за NodePort ресурс е 30000-32767. Избрахме порт 30033 за балансирани връзки с MySQL, който е съпоставен с порт 6033 на ProxySQL модулите и порт 30032 за порт за администриране на ProxySQL, съпоставен с 6032.

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

  • ConfigMap – За да съхранявате конфигурационния файл на ProxySQL като том, така че да може да бъде монтиран към множество модули и да бъде монтиран отново, ако модулът се пренасрочи към другия възел на Kubernetes.

Подготовка на ConfigMap за ProxySQL

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

Първо, създайте конфигурационния файл на ProxySQL, proxysql.cnf и добавете следните редове:

datadir="/var/lib/proxysql"
admin_variables=
{
        admin_credentials="proxysql-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_replication_hostgroups =
(
        { writer_hostgroup=10, reader_hostgroup=20, comment="MySQL Replication 5.7" }
)
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
        }
)

Обърнете внимание на admin_variables.admin_credentials променлива, където използвахме потребител, който не е по подразбиране, който е "proxysql-admin". ProxySQL запазва потребителя по подразбиране "admin" за локална връзка само чрез localhost. Следователно трябва да използваме други потребители за отдалечен достъп до екземпляра на ProxySQL. В противен случай ще получите следната грешка:

ERROR 1040 (42000): User 'admin' can only connect locally

Нашата конфигурация на ProxySQL се основава на нашите два сървъра на бази данни, работещи в 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

Wordpress Pod и дефиниция на услугата

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  replicas: 3
  selector:
    matchLabels:
      app: wordpress
      tier: frontend
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: wordpress
        tier: frontend
    spec:
      restartPolicy: Always
      containers:
      - image: wordpress:4.9-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: proxysql:6033 # proxysql.default.svc.cluster.local:6033
        - name: WORDPRESS_DB_USER
          value: wordpress
        - name: WORDPRESS_DB_DATABASE
          value: wordpress
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 80
          name: wordpress
---
apiVersion: v1
kind: Service
metadata:
  name: wordpress
  labels:
    app: wordpress
    tier: frontend
spec:
  type: NodePort
  ports:
  - name: wordpress
    nodePort: 30088
    port: 80
  selector:
    app: wordpress
    tier: frontend

Подобно на нашата дефиниция на ProxySQL, YAML се състои от два ресурса, разделени с разделител "---", комбинирани във файл. Първият е ресурсът за внедряване, който ще бъде разгърнат като ReplicaSet, както е показано в секцията "спец.*":

spec:
  replicas: 3
  selector:
    matchLabels:
      app: wordpress
      tier: frontend
  strategy:
    type: RollingUpdate

Този раздел предоставя спецификацията за внедряване - 3 модула за стартиране, които съответстват на етикета "app=wordpress,tier=backend". Стратегията за внедряване е RollingUpdate, което означава, че начинът, по който Kubernetes ще замени модула, е чрез използване на мода за непрекъснато актуализиране, същото с нашето внедряване на ProxySQL.

Следващата част е разделът "spec.template.spec.*":

      restartPolicy: Always
      containers:
      - image: wordpress:4.9-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: proxysql:6033
        - 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


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

  • WORDPRESS_DB_HOST - Хостът на базата данни MySQL. Тъй като използваме ProxySQL като услуга, името на услугата ще бъде стойността на metadata.name което е "proxysql". ProxySQL слуша на порт 6033 за връзки с балансирано натоварване на MySQL, докато административната конзола на ProxySQL е на 6032.
  • WORDPRESS_DB_USER - Посочете потребителя на базата данни на WordPress, който е създаден в секцията „Подготовка на базата данни“.
  • WORDPRESS_DB_PASSWORD - Паролата за WORDPRESS_DB_USER . Тъй като не искаме да разкриваме паролата в този файл, можем да я скрием с помощта на Kubernetes Secrets. Тук инструктираме Kubernetes да прочете тайния ресурс "mysql-pass". Тайните трябва да бъдат създадени предварително преди разполагането на модула, както е обяснено по-долу.

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

След прекъсващия ред „---“ дефинираме друг ресурс, наречен Service:

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

В тази конфигурация бихме искали Kubernetes да създаде услуга, наречена "wordpress", да слуша порт 30088 на всички възли (известен още като NodePort) към външната мрежа и да го препрати към порт 80 на всички модули, етикетирани с "app=wordpress,tier=преден интерфейс".

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

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

Подготовка на постоянно хранилище за Wordpress

Доброто постоянно съхранение за 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: wordpress
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: wordpress
      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

Подготовка на Secrets за Wordpress

Създайте тайна, която да се използва от контейнера на 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

Разгръщане на ProxySQL и Wordpress

Най-накрая можем да започнем внедряването. Първо внедрете ProxySQL, последвано от Wordpress:

$ kubectl create -f proxysql-rs-svc.yml
$ kubectl create -f wordpress-rs-svc.yml

След това можем да изброим всички модули и услуги, които са създадени под ниво "frontend":

$ kubectl get pods,services -l tier=frontend -o wide
NAME                             READY   STATUS    RESTARTS   AGE   IP          NODE          NOMINATED NODE
pod/proxysql-95b8d8446-qfbf2     1/1     Running   0          12m   10.36.0.2   kube2.local   <none>
pod/proxysql-95b8d8446-vljlr     1/1     Running   0          12m   10.44.0.6   kube3.local   <none>
pod/wordpress-59489d57b9-4dzvk   1/1     Running   0          37m   10.36.0.1   kube2.local   <none>
pod/wordpress-59489d57b9-7d2jb   1/1     Running   0          30m   10.44.0.4   kube3.local   <none>
pod/wordpress-59489d57b9-gw4p9   1/1     Running   0          30m   10.36.0.3   kube2.local   <none>

NAME                TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)                         AGE   SELECTOR
service/proxysql    NodePort   10.108.195.54    <none>        6033:30033/TCP,6032:30032/TCP   10m   app=proxysql,tier=frontend
service/wordpress   NodePort   10.109.144.234   <none>        80:30088/TCP                    37m   app=wordpress,tier=frontend
  kube2.local   <none>

Горният изход потвърждава нашата архитектура за внедряване, където в момента имаме три модула на Wordpress, изложени публично на порт 30088, както и на нашия ProxySQL екземпляр, който е изложен на порт 30033 и 30032 външно плюс 6033 и 6032 вътрешно.

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

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

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

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

ProxySQL модули и управление на услуги

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

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

Свързване с ProxySQL

Докато ProxySQL е изложен външно на порт 30033 (MySQL) и 30032 (Admin), той също е достъпен вътрешно чрез публикуваните портове, съответно 6033 и 6032. По този начин, за достъп до екземплярите на ProxySQL в мрежата на Kubernetes, използвайте CLUSTER-IP или името на услугата "proxysql" като стойност на хоста. Например, в рамките на Wordpress pod, можете да получите достъп до ProxySQL администраторската конзола, като използвате следната команда:

$ mysql -uproxysql-admin -p -hproxysql -P6032

Ако искате да се свържете външно, използвайте порта, дефиниран под стойността на nodePort, той обслужва YAML и изберете някой от възела Kubernetes като стойност на хоста:

$ mysql -uproxysql-admin -p -hkube3.local -P30032

Същото важи и за връзката с балансирано натоварване на MySQL на порт 30033 (външен) и 6033 (вътрешен).

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

Увеличаването е лесно с Kubernetes:

$ kubectl scale deployment proxysql --replicas=5
deployment.extensions/proxysql scaled

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

$ kubectl rollout status deployment proxysql
deployment "proxysql" successfully rolled out

Намаляването също е подобно. Тук искаме да се върнем от 5 на 2 реплики:

$ kubectl scale deployment proxysql --replicas=2
deployment.extensions/proxysql scaled

Можем също да разгледаме събитията за внедряване на ProxySQL, за да получим по-добра представа за това, което се е случило за това внедряване, като използваме опцията „описание“:

$ kubectl describe deployment proxysql
...
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  20m    deployment-controller  Scaled up replica set proxysql-769895fbf7 to 1
  Normal  ScalingReplicaSet  20m    deployment-controller  Scaled down replica set proxysql-95b8d8446 to 1
  Normal  ScalingReplicaSet  20m    deployment-controller  Scaled up replica set proxysql-769895fbf7 to 2
  Normal  ScalingReplicaSet  20m    deployment-controller  Scaled down replica set proxysql-95b8d8446 to 0
  Normal  ScalingReplicaSet  7m10s  deployment-controller  Scaled up replica set proxysql-6c55f647cb to 1
  Normal  ScalingReplicaSet  7m     deployment-controller  Scaled down replica set proxysql-769895fbf7 to 1
  Normal  ScalingReplicaSet  7m     deployment-controller  Scaled up replica set proxysql-6c55f647cb to 2
  Normal  ScalingReplicaSet  6m53s  deployment-controller  Scaled down replica set proxysql-769895fbf7 to 0
  Normal  ScalingReplicaSet  54s    deployment-controller  Scaled up replica set proxysql-6c55f647cb to 5
  Normal  ScalingReplicaSet  21s    deployment-controller  Scaled down replica set proxysql-6c55f647cb to 2

Връзките към модулите ще бъдат балансирани автоматично от Kubernetes.

Промени в конфигурацията

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

$ vim /root/proxysql.cnf

След това го заредете в Kubernetes ConfigMap с различно име. В този пример добавяме "-v2" в името на ресурса:

$ kubectl create configmap proxysql-configmap-v2 --from-file=proxysql.cnf

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

$ kubectl get configmap
NAME                    DATA   AGE
proxysql-configmap      1      3d15h
proxysql-configmap-v2   1      19m

Отворете файла за внедряване на ProxySQL, proxysql-rs-svc.yml и променете следния ред в секцията configMap на новата версия:

      volumes:
      - name: proxysql-config
        configMap:
          name: proxysql-configmap-v2 #change this line

След това приложете промените към нашето внедряване на ProxySQL:

$ kubectl apply -f proxysql-rs-svc.yml
deployment.apps/proxysql configured
service/proxysql configured

Проверете разпространението, като погледнете събитието ReplicaSet с флага „описание“:

$ kubectl describe proxysql
...
Pod Template:
  Labels:  app=proxysql
           tier=frontend
  Containers:
   proxysql:
    Image:        severalnines/proxysql:1.4.12
    Ports:        6033/TCP, 6032/TCP
    Host Ports:   0/TCP, 0/TCP
    Environment:  <none>
    Mounts:
      /etc/proxysql.cnf from proxysql-config (rw)
  Volumes:
   proxysql-config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      proxysql-configmap-v2
    Optional:  false
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   proxysql-769895fbf7 (2/2 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  53s   deployment-controller  Scaled up replica set proxysql-769895fbf7 to 1
  Normal  ScalingReplicaSet  46s   deployment-controller  Scaled down replica set proxysql-95b8d8446 to 1
  Normal  ScalingReplicaSet  46s   deployment-controller  Scaled up replica set proxysql-769895fbf7 to 2
  Normal  ScalingReplicaSet  41s   deployment-controller  Scaled down replica set proxysql-95b8d8446 to 0

Обърнете внимание на секцията "Обеми" с новото име на ConfigMap. Можете също да видите събитията за внедряване в долната част на изхода. В този момент новата ни конфигурация беше заредена във всички ProxySQL модули, където Kubernetes намали ProxySQL ReplicaSet до 0 (спазвайки стратегията RollingUpdate) и ги върна в желаното състояние от 2 реплики.

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

До този момент ние покрихме възможния подход за разгръщане на ProxySQL в Kubernetes. Изпълнението на ProxySQL с помощта на Kubernetes ConfigMap отваря нова възможност за ProxySQL клъстериране, където то е малко по-различно в сравнение с вградената в ProxySQL поддръжка за клъстериране в собствен произход.

В предстоящата публикация в блога ще разгледаме ProxySQL клъстерирането с помощта на Kubernetes ConfigMap и как да го направите по правилния начин. Останете на линия!


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. AWS RDS:„SQLSTATE[22001] – Данните са твърде дълги за колона“ с помощта на MariaDB 10.2

  2. Съвети за наблюдение на репликацията на MariaDB с ClusterControl

  3. Как работи RAND() в MariaDB

  4. ClusterControl:Въведение в новия монитор на заявки

  5. Преместване на база данни на MariaDB в криптирани и некриптирани състояния