MariaDB
 sql >> Teknologi Basis Data >  >> RDS >> MariaDB

Menjalankan ProxySQL sebagai Layanan Kubernetes

Saat menjalankan klaster basis data terdistribusi, cukup umum untuk mengungguli mereka dengan penyeimbang beban. Keuntungannya jelas - load balancing, koneksi failover dan decoupling tingkat aplikasi dari topologi database yang mendasarinya. Untuk penyeimbangan beban yang lebih cerdas, proxy berbasis basis data seperti ProxySQL atau MaxScale akan menjadi cara yang tepat. Di blog kami sebelumnya, kami menunjukkan cara menjalankan ProxySQL sebagai wadah pembantu di Kubernetes. Dalam posting blog ini, kami akan menunjukkan cara menerapkan ProxySQL sebagai layanan Kubernetes. Kami akan menggunakan Wordpress sebagai contoh aplikasi dan database backend berjalan pada Replikasi MySQL dua-simpul yang digunakan menggunakan ClusterControl. Diagram berikut menggambarkan infrastruktur kami:

Karena kita akan menerapkan pengaturan yang sama seperti pada entri blog sebelumnya, harap duplikasi di beberapa bagian entri blog agar entri lebih mudah dibaca.

ProxySQL di Kubernetes

Mari kita mulai dengan sedikit rekap. Merancang arsitektur ProxySQL adalah topik subjektif dan sangat tergantung pada penempatan aplikasi, wadah database, serta peran ProxySQL itu sendiri. Idealnya, kita dapat mengonfigurasi ProxySQL untuk dikelola oleh Kubernetes dengan dua konfigurasi:

  1. ProxySQL sebagai layanan Kubernetes (penyebaran terpusat)
  2. ProxySQL sebagai wadah pembantu dalam pod (penyebaran terdistribusi)

Kedua penerapan dapat dibedakan dengan mudah dengan melihat diagram berikut:

Posting blog ini akan membahas konfigurasi pertama - menjalankan ProxySQL sebagai layanan Kubernetes. Konfigurasi kedua sudah dibahas di sini. Berbeda dengan pendekatan helper container, berjalan sebagai layanan membuat pod ProxySQL hidup secara independen dari aplikasi dan dapat dengan mudah diskalakan dan dikelompokkan bersama dengan bantuan Kubernetes ConfigMap. Ini jelas merupakan pendekatan pengelompokan yang berbeda dari dukungan pengelompokan asli ProxySQL yang bergantung pada checksum konfigurasi di seluruh instance ProxySQL (alias proxysql_servers). Lihat posting blog ini jika Anda ingin mempelajari pengelompokan ProxySQL yang dibuat mudah dengan ClusterControl.

Di Kubernetes, sistem konfigurasi multi-layer ProxySQL memungkinkan pengelompokan pod dengan ConfigMap. Namun, ada sejumlah kekurangan dan solusi untuk membuatnya bekerja dengan lancar seperti yang dilakukan fitur pengelompokan asli ProxySQL. Saat ini, menandakan pod pada pembaruan ConfigMap adalah fitur yang sedang dikerjakan. Kami akan membahas topik ini secara lebih mendetail dalam entri blog mendatang.

Pada dasarnya, kita perlu membuat pod ProxySQL dan melampirkan layanan Kubernetes agar dapat diakses oleh pod lain di dalam jaringan Kubernetes atau secara eksternal. Aplikasi kemudian akan terhubung ke layanan ProxySQL melalui jaringan TCP/IP pada port yang dikonfigurasi. Default ke 6033 untuk koneksi seimbang beban MySQL dan 6032 untuk konsol administrasi ProxySQL. Dengan lebih dari satu replika, koneksi ke pod akan diseimbangkan beban secara otomatis oleh komponen kube-proxy Kubernetes yang berjalan di setiap node Kubernetes.

ProxySQL sebagai Layanan Kubernetes

Dalam pengaturan ini, kami menjalankan ProxySQL dan Wordpress sebagai pod dan layanan. Diagram berikut menggambarkan arsitektur tingkat tinggi kami:

Dalam pengaturan ini, kami akan menerapkan dua pod dan layanan - "wordpress" dan "proxysql". Kami akan menggabungkan deklarasi Deployment dan Service dalam satu file YAML per aplikasi dan mengelolanya sebagai satu unit. Untuk menjaga agar konten wadah aplikasi tetap ada di beberapa node, kita harus menggunakan sistem file yang dikelompokkan atau jauh, yang dalam hal ini adalah NFS.

Menyebarkan ProxySQL sebagai layanan membawa beberapa hal baik melalui pendekatan wadah pembantu:

  • Menggunakan pendekatan Kubernetes ConfigMap, ProxySQL dapat dikelompokkan dengan konfigurasi yang tidak dapat diubah.
  • Kubernetes menangani pemulihan ProxySQL dan menyeimbangkan koneksi ke instance secara otomatis.
  • Titik akhir tunggal dengan implementasi alamat IP Virtual Kubernetes yang disebut ClusterIP.
  • Tingkat proxy terbalik terpusat dengan arsitektur apa pun yang tidak dibagikan.
  • Dapat digunakan dengan aplikasi eksternal di luar Kubernetes.

Kami akan memulai penerapan sebagai dua replika untuk ProxySQL dan tiga untuk Wordpress untuk mendemonstrasikan kemampuan berjalan pada skala dan keseimbangan beban yang ditawarkan Kubernetes.

Menyiapkan Basis Data

Buat database dan pengguna wordpress di master dan tetapkan dengan hak istimewa yang benar:

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

Juga, buat pengguna pemantauan ProxySQL:

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

Kemudian, muat ulang tabel hibah:

mysql-master> FLUSH PRIVILEGES;

Definisi Pod dan Layanan ProxySQL

Yang berikutnya adalah mempersiapkan penyebaran ProxySQL kami. Buat file bernama proxysql-rs-svc.yml dan tambahkan baris berikut:

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

Mari kita lihat apa definisi tersebut. YAML terdiri dari dua sumber daya yang digabungkan dalam sebuah file, dipisahkan oleh pembatas "---". Sumber daya pertama adalah Deployment, yang kami definisikan dengan spesifikasi berikut:

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

Hal di atas berarti kita ingin men-deploy dua pod ProxySQL sebagai ReplicaSet yang cocok dengan container berlabel "app=proxysql,tier=frontend". Strategi penyebaran menentukan strategi yang digunakan untuk mengganti pod lama dengan yang baru. Dalam penerapan ini, kami memilih RollingUpdate yang berarti pod akan diperbarui dengan cara pembaruan bergulir, satu pod pada satu waktu.

Bagian selanjutnya adalah template container:

      - 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

Dalam spec.templates.spec.containers.* bagian, kami memberi tahu Kubernetes untuk menerapkan ProxySQL menggunakan severalnines/proxysql versi gambar 1.4.12. Kami juga ingin Kubernetes me-mount file konfigurasi kustom kami yang telah dikonfigurasi sebelumnya dan memetakannya ke /etc/proxysql.cnf di dalam container. Pod yang berjalan akan memublikasikan dua port - 6033 dan 6032. Kami juga mendefinisikan bagian "volume", di mana kami menginstruksikan Kubernetes untuk memasang ConfigMap sebagai volume di dalam pod ProxySQL untuk dipasang oleh volumeMounts.

Sumber daya kedua adalah layanan. Layanan Kubernetes adalah lapisan abstraksi yang mendefinisikan kumpulan logis dari pod dan kebijakan untuk mengaksesnya. Di bagian ini, kami mendefinisikan yang berikut:

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

Dalam hal ini, kami ingin ProxySQL kami diakses dari jaringan eksternal sehingga tipe NodePort adalah tipe yang dipilih. Ini akan memublikasikan nodePort pada setiap node Kubernetes di cluster. Kisaran port yang valid untuk sumber daya NodePort adalah 30000-32767. Kami memilih port 30033 untuk koneksi seimbang beban MySQL yang dipetakan ke port 6033 dari pod ProxySQL dan port 30032 untuk port Administrasi ProxySQL yang dipetakan ke 6032.

Oleh karena itu, berdasarkan definisi YAML kita di atas, kita harus menyiapkan resource Kubernetes berikut sebelum kita dapat mulai men-deploy pod "proxysql":

  • ConfigMap - Untuk menyimpan file konfigurasi ProxySQL sebagai volume sehingga dapat di-mount ke beberapa pod dan dapat di-remount lagi jika pod dijadwal ulang ke node Kubernetes lainnya.

Menyiapkan ConfigMap untuk ProxySQL

Mirip dengan posting blog sebelumnya, kita akan menggunakan pendekatan ConfigMap untuk memisahkan file konfigurasi dari wadah dan juga untuk tujuan skalabilitas. Perhatikan bahwa dalam pengaturan ini, kami menganggap konfigurasi ProxySQL kami tidak dapat diubah.

Pertama, buat file konfigurasi ProxySQL, proxysql.cnf dan tambahkan baris berikut:

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
        }
)

Perhatikan admin_variables.admin_credentials variabel di mana kami menggunakan pengguna non-default yaitu "proxysql-admin". ProxySQL mencadangkan pengguna "admin" default untuk koneksi lokal hanya melalui localhost. Oleh karena itu, kita harus menggunakan pengguna lain untuk mengakses instance ProxySQL dari jarak jauh. Jika tidak, Anda akan mendapatkan kesalahan berikut:

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

Konfigurasi ProxySQL kami didasarkan pada dua server database kami yang berjalan di Replikasi MySQL seperti yang dirangkum dalam tangkapan layar Topologi berikut yang diambil dari ClusterControl:

Semua penulisan harus masuk ke node master sementara pembacaan diteruskan ke hostgroup 20, seperti yang didefinisikan di bagian "mysql_query_rules". Itulah dasar dari pemisahan baca/tulis dan kami ingin menggunakannya secara bersamaan.

Kemudian, impor file konfigurasi ke ConfigMap:

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

Verifikasi apakah ConfigMap dimuat ke Kubernetes:

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

Definisi Pod dan Layanan Wordpress

Sekarang, rekatkan baris berikut ke dalam file bernama wordpress-rs-svc.yml pada host tempat kubectl dikonfigurasi:

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

Mirip dengan definisi ProxySQL kami, YAML terdiri dari dua sumber daya, dipisahkan oleh pembatas "---" yang digabungkan dalam sebuah file. Yang pertama adalah Deployment resource, yang akan di-deploy sebagai ReplicaSet, seperti yang ditunjukkan di bawah bagian "spec.*":

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

Bagian ini menyediakan spesifikasi Deployment - 3 pod untuk memulai yang cocok dengan label "app=wordpress,tier=backend". Strategi penerapannya adalah RollingUpdate yang berarti cara Kubernetes mengganti pod adalah dengan menggunakan mode pembaruan bergulir, sama dengan penerapan ProxySQL kami.

Bagian selanjutnya adalah bagian "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


Pada bagian ini, kami memberi tahu Kubernetes untuk menerapkan Wordpress 4.9 menggunakan server web Apache dan kami memberi nama wadah itu "wordpress". Penampung akan dimulai ulang setiap kali mati, apa pun statusnya. Kami juga ingin Kubernetes meneruskan sejumlah variabel lingkungan:

  • WORDPRESS_DB_HOST - Host basis data MySQL. Karena kami menggunakan ProxySQL sebagai layanan, nama layanan akan menjadi nilai metadata.name yaitu "proxysql". ProxySQL mendengarkan pada port 6033 untuk koneksi beban seimbang MySQL sementara konsol administrasi ProxySQL pada 6032.
  • WORDPRESS_DB_USER - Tentukan pengguna database wordpress yang telah dibuat pada bagian "Menyiapkan Database".
  • WORDPRESS_DB_PASSWORD - Kata sandi untuk WORDPRESS_DB_USER . Karena kami tidak ingin mengekspos kata sandi dalam file ini, kami dapat menyembunyikannya menggunakan Rahasia Kubernetes. Di sini kami menginstruksikan Kubernetes untuk membaca sumber daya Rahasia "mysql-pass". Rahasia harus dibuat terlebih dahulu sebelum penyebaran pod, seperti yang dijelaskan lebih lanjut di bawah.

Kami juga ingin memublikasikan port 80 pod untuk pengguna akhir. Konten Wordpress yang disimpan di dalam /var/www/html dalam wadah akan dipasang ke penyimpanan persisten kami yang berjalan di NFS. Kami akan menggunakan sumber daya PersistentVolume dan PersistentVolumeClaim untuk tujuan ini seperti yang ditunjukkan pada bagian "Menyiapkan Penyimpanan Persisten untuk Wordpress".

Setelah break line "---", kita mendefinisikan resource lain yang disebut 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

Dalam konfigurasi ini, kami ingin Kubernetes membuat layanan yang disebut "wordpress", mendengarkan pada port 30088 pada semua node (alias NodePort) ke jaringan eksternal dan meneruskannya ke port 80 pada semua pod yang berlabel "app=wordpress,tier=bagian depan".

Oleh karena itu, berdasarkan definisi YAML kami di atas, kami harus menyiapkan sejumlah sumber daya Kubernetes sebelum kami dapat mulai men-deploy pod dan layanan "wordpress":

  • Volume Persisten dan PersistentVolumeClaim - Untuk menyimpan konten web dari aplikasi Wordpress kita, jadi ketika pod sedang dijadwal ulang ke node pekerja lain, kita tidak akan kehilangan perubahan terakhir.
  • Rahasia - Untuk menyembunyikan kata sandi pengguna database Wordpress di dalam file YAML.

Menyiapkan Penyimpanan Persisten untuk Wordpress

Penyimpanan persisten yang baik untuk Kubernetes harus dapat diakses oleh semua node Kubernetes dalam cluster. Demi posting blog ini, kami menggunakan NFS sebagai penyedia PersistentVolume (PV) karena mudah dan didukung langsung. Server NFS terletak di suatu tempat di luar jaringan Kubernetes kami (seperti yang ditunjukkan pada diagram arsitektur pertama) dan kami telah mengonfigurasinya untuk mengizinkan semua node Kubernetes dengan baris berikut di dalam /etc/exports:

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

Perhatikan bahwa paket klien NFS harus diinstal pada semua node Kubernetes. Jika tidak, Kubernetes tidak akan dapat memasang NFS dengan benar. Di semua node:

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

Juga, pastikan di server NFS, direktori target ada:

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

Kemudian, buat file bernama wordpress-pv-pvc.yml dan tambahkan baris berikut:

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

Dalam definisi di atas, kami memberi tahu Kubernetes untuk mengalokasikan ruang volume 3GB di server NFS untuk wadah Wordpress kami. Perhatikan untuk penggunaan produksi, NFS harus dikonfigurasi dengan penyedia otomatis dan kelas penyimpanan.

Buat sumber daya PV dan PVC:

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

Verifikasi apakah sumber daya tersebut dibuat dan statusnya harus "Terikat":

$ 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

Menyiapkan Rahasia untuk Wordpress

Buat rahasia untuk digunakan oleh wadah Wordpress untuk WORDPRESS_DB_PASSWORD variabel lingkungan. Alasannya hanya karena kami tidak ingin mengekspos kata sandi dalam teks yang jelas di dalam file YAML.

Buat sumber rahasia bernama mysql-pass dan berikan kata sandi yang sesuai:

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

Verifikasi bahwa rahasia kami telah dibuat:

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

Menyebarkan ProxySQL dan Wordpress

Akhirnya, kita bisa memulai penyebaran. Terapkan ProxySQL terlebih dahulu, diikuti oleh Wordpress:

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

Kami kemudian dapat membuat daftar semua pod dan layanan yang telah dibuat di bawah tingkat "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>

Output di atas memverifikasi arsitektur penerapan kami di mana kami saat ini memiliki tiga pod Wordpress, yang diekspos pada port 30088 secara publik serta instans ProxySQL kami yang diekspos pada port 30033 dan 30032 secara eksternal ditambah 6033 dan 6032 secara internal.

Pada titik ini, arsitektur kita terlihat seperti ini:

Port 80 yang diterbitkan oleh pod Wordpress sekarang dipetakan ke dunia luar melalui port 30088. Kita dapat mengakses posting blog kita di http://{any_kubernetes_host}:30088/ dan harus diarahkan ke halaman instalasi Wordpress. Jika kita melanjutkan instalasi, itu akan melewati bagian koneksi database dan langsung menampilkan halaman ini:

Ini menunjukkan bahwa konfigurasi MySQL dan ProxySQL kami dikonfigurasi dengan benar di dalam file wp-config.php. Jika tidak, Anda akan diarahkan ke halaman konfigurasi database.

Penerapan kami sekarang selesai.

Pod ProxySQL dan Manajemen Layanan

Failover dan pemulihan diharapkan akan ditangani secara otomatis oleh Kubernetes. Misalnya, jika pekerja Kubernetes down, pod akan dibuat ulang di node berikutnya yang tersedia setelah --pod-eviction-timeout (default pada 5 menit). Jika container mogok atau mati, Kubernetes akan segera menggantinya.

Beberapa tugas manajemen umum diharapkan berbeda saat dijalankan di dalam Kubernetes, seperti yang ditunjukkan di bagian selanjutnya.

Menghubungkan ke ProxySQL

Sementara ProxySQL diekspos secara eksternal pada port 30033 (MySQL) dan 30032 (Admin), ProxySQL juga dapat diakses secara internal melalui port yang diterbitkan, masing-masing 6033 dan 6032. Jadi, untuk mengakses instance ProxySQL dalam jaringan Kubernetes, gunakan CLUSTER-IP, atau nama layanan "proxysql" sebagai nilai host. Misalnya, dalam pod Wordpress, Anda dapat mengakses konsol admin ProxySQL dengan menggunakan perintah berikut:

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

Jika Anda ingin terhubung secara eksternal, gunakan port yang ditentukan di bawah nilai nodePort yang melayani YAML dan pilih salah satu node Kubernetes sebagai nilai host:

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

Hal yang sama berlaku untuk koneksi seimbang beban MySQL pada port 30033 (eksternal) dan 6033 (internal).

Penskalaan Naik dan Turun

Meningkatkan skala dengan mudah dengan Kubernetes:

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

Verifikasi status peluncuran:

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

Memperkecil juga serupa. Di sini kami ingin mengembalikan dari 5 menjadi 2 replika:

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

Kami juga dapat melihat peristiwa penerapan untuk ProxySQL untuk mendapatkan gambaran yang lebih baik tentang apa yang telah terjadi untuk penerapan ini dengan menggunakan opsi "jelaskan":

$ 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

Koneksi ke pod akan diseimbangkan beban secara otomatis oleh Kubernetes.

Perubahan Konfigurasi

Salah satu cara untuk membuat perubahan konfigurasi pada pod ProxySQL kami adalah dengan membuat versi konfigurasi kami menggunakan nama ConfigMap lain. Pertama, ubah file konfigurasi kami secara langsung melalui editor teks favorit Anda:

$ vim /root/proxysql.cnf

Kemudian, muat ke Kubernetes ConfigMap dengan nama yang berbeda. Dalam contoh ini, kami menambahkan "-v2" di nama sumber daya:

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

Verifikasi apakah ConfigMap dimuat dengan benar:

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

Buka file penerapan ProxySQL, proxysql-rs-svc.yml dan ubah baris berikut di bawah bagian configMap ke versi baru:

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

Kemudian, terapkan perubahan pada penerapan ProxySQL kami:

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

Verifikasi peluncuran dengan melihat event ReplicaSet menggunakan flag "describe":

$ 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

Perhatikan bagian "Volume" dengan nama ConfigMap baru. Anda juga dapat melihat peristiwa penerapan di bagian bawah output. Pada titik ini, konfigurasi baru kami telah dimuat ke semua pod ProxySQL, di mana Kubernetes menurunkan ProxySQL ReplicaSet ke 0 (mematuhi strategi RollingUpdate) dan mengembalikannya ke status 2 replika yang diinginkan.

Pemikiran Terakhir

Sampai saat ini, kami telah membahas kemungkinan pendekatan penerapan untuk ProxySQL di Kubernetes. Menjalankan ProxySQL dengan bantuan Kubernetes ConfigMap membuka kemungkinan baru pengelompokan ProxySQL, yang agak berbeda dibandingkan dengan dukungan pengelompokan asli yang ada di dalam ProxySQL.

Dalam posting blog yang akan datang, kita akan menjelajahi Clustering ProxySQL menggunakan Kubernetes ConfigMap dan bagaimana melakukannya dengan cara yang benar. Tetap disini!


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

  1. Failover Tingkat Lanjut Menggunakan Kait Skrip Post/pra

  2. Enkripsi MariaDB Penuh Saat Istirahat dan Dalam Perjalanan untuk Perlindungan Data Maksimum - Bagian Satu

  3. Postingan Blog Basis Data Terpopuler Kami di Tahun 2017

  4. Bagaimana SOUNDEX() Bekerja di MariaDB

  5. Tips dan Trik untuk Menerapkan Kontrol Akses Berbasis Peran Database untuk MariaDB