ProxySQL biasanya berada di antara tingkat aplikasi dan basis data, yang disebut tingkat proxy terbalik. Saat container aplikasi Anda diatur dan dikelola oleh Kubernetes, Anda mungkin ingin menggunakan ProxySQL di depan server database Anda.
Dalam postingan ini, kami akan menunjukkan cara menjalankan ProxySQL di Kubernetes sebagai wadah pembantu dalam sebuah pod. Kita akan menggunakan Wordpress sebagai contoh aplikasi. Layanan data disediakan oleh Replikasi MySQL dua simpul kami, disebarkan menggunakan ClusterControl dan berada di luar jaringan Kubernetes pada infrastruktur bare-metal, seperti yang diilustrasikan dalam diagram berikut:
Gambar Docker ProxySQL
Dalam contoh ini, kita akan menggunakan image ProxySQL Docker yang dikelola oleh Somenines, image publik umum yang dibuat untuk penggunaan multiguna. Gambar datang tanpa skrip entrypoint dan mendukung Galera Cluster (selain dukungan bawaan untuk Replikasi MySQL), di mana skrip tambahan diperlukan untuk tujuan health check.
Pada dasarnya, untuk menjalankan wadah ProxySQL, cukup jalankan perintah berikut:
$ docker run -d -v /path/to/proxysql.cnf:/etc/proxysql.cnf severalnines/proxysqlGambar ini menyarankan Anda untuk mengikat file konfigurasi ProxySQL ke titik pemasangan, /etc/proxysql.cnf, meskipun Anda dapat melewati ini dan mengonfigurasinya nanti menggunakan konsol Admin ProxySQL. Contoh konfigurasi disediakan di halaman Docker Hub atau halaman Github.
ProxySQL di Kubernetes
Merancang arsitektur ProxySQL adalah topik subjektif dan sangat tergantung pada penempatan wadah aplikasi dan database serta peran ProxySQL itu sendiri. ProxySQL tidak hanya merutekan kueri, tetapi juga dapat digunakan untuk menulis ulang dan menyimpan kueri. Klik cache yang efisien mungkin memerlukan konfigurasi khusus yang disesuaikan secara khusus untuk beban kerja database aplikasi.
Idealnya, kita dapat mengonfigurasi ProxySQL untuk dikelola oleh Kubernetes dengan dua konfigurasi:
- ProxySQL sebagai layanan Kubernetes (penyebaran terpusat).
- ProxySQL sebagai wadah pembantu dalam pod (penyebaran terdistribusi).
Opsi pertama cukup mudah, di mana kita membuat pod ProxySQL dan melampirkan layanan Kubernetes ke dalamnya. Aplikasi kemudian akan terhubung ke layanan ProxySQL melalui jaringan pada port yang dikonfigurasi. Default ke 6033 untuk port MySQL load-balanced dan 6032 untuk port administrasi ProxySQL. Penerapan ini akan dibahas dalam entri blog mendatang.
Opsi kedua sedikit berbeda. Kubernetes memiliki konsep yang disebut "pod". Anda dapat memiliki satu atau lebih wadah per pod, ini relatif erat. Konten pod selalu ditempatkan bersama dan dijadwalkan bersama, dan dijalankan dalam konteks bersama. Pod adalah unit container terkecil yang dapat dikelola di Kubernetes.
Kedua penerapan dapat dibedakan dengan mudah dengan melihat diagram berikut:
Alasan utama pod dapat memiliki banyak container adalah untuk mendukung aplikasi pembantu yang membantu aplikasi utama. Contoh umum dari aplikasi pembantu adalah penarik data, pendorong data, dan proxy. Helper dan aplikasi utama sering kali perlu berkomunikasi satu sama lain. Biasanya ini dilakukan melalui sistem file bersama, seperti yang ditunjukkan dalam latihan ini, atau melalui antarmuka jaringan loopback, localhost. Contoh pola ini adalah server web bersama dengan program pembantu yang melakukan polling pada repositori Git untuk pembaruan baru.
Postingan blog ini akan membahas konfigurasi kedua - menjalankan ProxySQL sebagai wadah pembantu dalam sebuah pod.
ProxySQL sebagai Helper dalam sebuah Pod
Dalam pengaturan ini, kami menjalankan ProxySQL sebagai wadah pembantu untuk wadah Wordpress kami. Diagram berikut menggambarkan arsitektur tingkat tinggi kami:
Dalam pengaturan ini, wadah ProxySQL digabungkan erat dengan wadah Wordpress, dan kami menamakannya sebagai pod "blog". Jika penjadwalan ulang terjadi, misalnya, node pekerja Kubernetes turun, kedua kontainer ini akan selalu dijadwal ulang bersama sebagai satu unit logis pada host berikutnya yang tersedia. Untuk menjaga konten wadah aplikasi tetap ada di beberapa node, kita harus menggunakan sistem file yang dikelompokkan atau jauh, yang dalam hal ini adalah NFS.
Peran proxySQL adalah untuk menyediakan lapisan abstraksi database ke wadah aplikasi. Karena kami menjalankan Replikasi MySQL dua simpul sebagai layanan database backend, pemisahan baca-tulis sangat penting untuk memaksimalkan konsumsi sumber daya di kedua server MySQL. ProxySQL unggul dalam hal ini dan membutuhkan sedikit atau tanpa perubahan pada aplikasi.
Ada sejumlah manfaat lain menjalankan ProxySQL dalam penyiapan ini:
- Membawa kemampuan caching kueri yang paling dekat dengan lapisan aplikasi yang berjalan di Kubernetes.
- Amankan implementasi dengan menghubungkan melalui file soket UNIX ProxySQL. Ini seperti pipa yang dapat digunakan server dan klien untuk terhubung dan bertukar permintaan dan data.
- Tingkat proxy terbalik terdistribusi dengan arsitektur apa-apa yang dibagikan.
- Overhead jaringan yang lebih sedikit karena penerapan "lewati-jaringan".
- Pendekatan penerapan stateless dengan memanfaatkan Kubernetes ConfigMaps.
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;Menyiapkan Pod
Sekarang, salin tempel baris berikut ke dalam file bernama blog-deployment.yml pada host tempat kubectl dikonfigurasi:
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: {}File YAML memiliki banyak baris dan mari kita lihat bagian yang menarik saja. Bagian pertama:
apiVersion: apps/v1
kind: DeploymentBaris pertama adalah apiVersion. Cluster Kubernetes kami berjalan pada v1.12 jadi kami harus merujuk ke dokumentasi API Kubernetes v1.12 dan mengikuti deklarasi sumber daya sesuai dengan API ini. Yang berikutnya adalah jenisnya, yang memberi tahu jenis sumber daya apa yang ingin kita gunakan. Deployment, Service, ReplicaSet, DaemonSet, PersistentVolume adalah beberapa contohnya.
Bagian penting berikutnya adalah bagian "wadah". Di sini kita mendefinisikan semua container yang ingin kita jalankan bersama di pod ini. Bagian pertama adalah wadah 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: /tmpDi bagian ini, kami memberi tahu Kubernetes untuk menerapkan Wordpress 4.9 menggunakan server web Apache dan kami memberi wadah tersebut nama "wordpress". Kami juga ingin Kubernetes meneruskan sejumlah variabel lingkungan:
- WORDPRESS_DB_HOST - Tuan rumah basis data. Karena container ProxySQL kita berada di Pod yang sama dengan container Wordpress, lebih aman menggunakan file soket ProxySQL. Format untuk menggunakan file socket di Wordpress adalah "localhost:{path to the socket file}". Secara default, itu terletak di bawah direktori /tmp dari wadah ProxySQL. Jalur /tmp ini dibagikan antara wadah Wordpress dan ProxySQL dengan menggunakan volumeMounts "data bersama" seperti yang ditunjukkan di bawah. Kedua kontainer harus memasang volume ini untuk berbagi konten yang sama di bawah direktori /tmp.
- WORDPRESS_DB_USER - Tentukan pengguna database wordpress.
- 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 container untuk pengguna akhir. Konten Wordpress yang disimpan di dalam /var/www/html dalam wadah akan dipasang ke penyimpanan persisten kami yang berjalan di NFS.
Selanjutnya, kita mendefinisikan wadah 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: proxysqlPada bagian di atas, kami memberi tahu Kubernetes untuk men-deploy 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. Akan ada volume yang disebut "shared-data" yang dipetakan ke direktori /tmp untuk dibagikan dengan image Wordpress - direktori sementara yang berbagi masa pakai pod. Hal ini memungkinkan file soket ProxySQL (/tmp/proxysql.sock) digunakan oleh wadah Wordpress saat menghubungkan ke database, melewati jaringan TCP/IP.
Bagian terakhir adalah bagian "volume":
volumes:
- name: wordpress-persistent-storage
persistentVolumeClaim:
claimName: wp-pv-claim
- name: proxysql-config
configMap:
name: proxysql-configmap
- name: shared-data
emptyDir: {}Kubernetes harus membuat tiga volume untuk pod ini:
- wordpress-persistent-storage - Gunakan PersistentVolumeClaim sumber daya untuk memetakan ekspor NFS ke dalam wadah untuk penyimpanan data persisten untuk konten Wordpress.
- proxysql-config - Gunakan ConfigMap sumber daya untuk memetakan file konfigurasi ProxySQL.
- data bersama - Gunakan emptyDir resource untuk memasang direktori bersama untuk container kita di dalam Pod. direktori kosong resource adalah direktori sementara yang berbagi masa pakai pod.
Oleh karena itu, berdasarkan definisi YAML kami di atas, kami harus menyiapkan sejumlah sumber daya Kubernetes sebelum kami dapat mulai men-deploy pod "blog":
- 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.
- ConfigMap - Untuk memetakan file konfigurasi ke wadah ProxySQL, sehingga ketika dijadwal ulang ke node lain, Kubernetes dapat secara otomatis me-remount ulang file tersebut.
PersistentVolume dan PersistentVolumeClaim
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 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/CentOSJuga, pastikan di server NFS, direktori target ada:
(nfs-server)$ mkdir /nfs/kubernetes/wordpressKemudian, buat file bernama wordpress-pv-pvc.yml dan tambahkan baris berikut:
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: frontendDalam definisi di atas, kami ingin Kubernetes 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.ymlVerifikasi 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 22hRahasia
Yang pertama adalah membuat rahasia yang akan 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=passw0rdVerifikasi bahwa rahasia kami telah dibuat:
$ kubectl get secrets mysql-pass
NAME TYPE DATA AGE
mysql-pass Opaque 1 7h12mConfigMap
Kita juga perlu membuat sumber daya ConfigMap untuk wadah ProxySQL kita. File Kubernetes ConfigMap menyimpan pasangan nilai kunci dari data konfigurasi yang dapat digunakan dalam pod atau digunakan untuk menyimpan data konfigurasi. ConfigMaps memungkinkan Anda untuk memisahkan artefak konfigurasi dari konten gambar agar aplikasi dalam container tetap portabel.
Karena server database kami sudah berjalan di server bare-metal dengan nama host statis dan alamat IP ditambah nama pengguna dan kata sandi pemantauan statis, dalam kasus penggunaan ini file ConfigMap akan menyimpan informasi konfigurasi yang telah dikonfigurasi sebelumnya tentang layanan ProxySQL yang ingin kita gunakan.
Pertama buat file teks bernama proxysql.cnf dan tambahkan baris berikut:
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" }
)Berikan perhatian ekstra pada bagian "mysql_servers" dan "mysql_users", di mana Anda mungkin perlu mengubah nilainya agar sesuai dengan pengaturan cluster database Anda. Dalam hal ini, kami memiliki dua server database 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 createdVerifikasi apakah ConfigMap dimuat ke Kubernetes:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 45sMenerapkan Pod
Sekarang kita harus menggunakan pod blog dengan baik. Kirim tugas penerapan ke Kubernetes:
$ kubectl create -f blog-deployment.ymlVerifikasi status pod:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
blog-54755cbcb5-t4cb7 2/2 Running 0 100sItu harus menunjukkan 2/2 di bawah kolom READY, menunjukkan ada dua kontainer yang berjalan di dalam pod. Gunakan tanda opsi -c untuk memeriksa wadah Wordpress dan ProxySQL di dalam pod blog:
$ kubectl logs blog-54755cbcb5-t4cb7 -c wordpress
$ kubectl logs blog-54755cbcb5-t4cb7 -c proxysqlDari log kontainer ProxySQL, Anda akan melihat baris berikut:
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 (writer hostgroup) hanya boleh memiliki satu node ONLINE (menunjukkan master tunggal) dan host lainnya harus setidaknya dalam status OFFLINE_HARD. Untuk HID 20, diharapkan ONLINE untuk semua node (menunjukkan beberapa replika baca).
Untuk mendapatkan ringkasan penerapan, gunakan tanda deskripsikan:
$ kubectl describe deployments blogBlog kami sekarang berjalan, namun kami tidak dapat mengaksesnya dari luar jaringan Kubernetes tanpa mengonfigurasi layanan, seperti yang dijelaskan di bagian selanjutnya.
Membuat Layanan Blog
Langkah terakhir adalah membuat attach a service ke pod kita. Ini untuk memastikan bahwa pod blog Wordpress kami dapat diakses dari dunia luar. Buat file bernama blog-svc.yml dan rekatkan baris berikut:
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: frontendBuat layanan:
$ kubectl create -f blog-svc.ymlVerifikasi apakah layanan dibuat dengan benar:
[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 43hPort 80 yang diterbitkan oleh blog pod sekarang dipetakan ke dunia luar melalui port 30080. Kita dapat mengakses posting blog kita di http://{any_kubernetes_host}:30080/ 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.
Mengelola Wadah ProxySQL di dalam Pod
Failover dan pemulihan diharapkan akan ditangani secara otomatis oleh Kubernetes. Misalnya, jika pekerja Kubernetes turun, 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 dalam Kubernetes, seperti yang ditunjukkan di bagian selanjutnya.
Penskalaan Naik dan Turun
Dalam konfigurasi di atas, kami menerapkan satu replika dalam penerapan kami. Untuk meningkatkan, cukup ubah spec.replicas nilai sesuai dengan menggunakan perintah edit kubectl:
$ kubectl edit deployment blogIni akan membuka definisi penerapan dalam file teks default dan cukup mengubah spec.replicas nilai untuk sesuatu yang lebih tinggi, misalnya, "replika:3". Kemudian, simpan file tersebut dan segera periksa status peluncuran dengan menggunakan perintah berikut:
$ 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 outPada titik ini, kami memiliki tiga pod blog (Wordpress + ProxySQL) yang berjalan secara bersamaan di 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 22mPada titik ini, arsitektur kita terlihat seperti ini:
Perhatikan bahwa mungkin memerlukan lebih banyak penyesuaian daripada konfigurasi kami saat ini untuk menjalankan Wordpress dengan lancar di lingkungan produksi skala horizontal (pikirkan tentang konten statis, manajemen sesi, dan lainnya). Itu sebenarnya di luar cakupan posting blog ini.
Prosedur penskalaan serupa.
Manajemen Konfigurasi
Manajemen konfigurasi penting dalam ProxySQL. Di sinilah keajaiban terjadi di mana Anda dapat menentukan seperangkat aturan kueri Anda sendiri untuk melakukan caching kueri, firewall, dan penulisan ulang. Berlawanan dengan praktik umum, di mana ProxySQL akan dikonfigurasi melalui konsol Admin dan mendorong ke persistensi dengan menggunakan "SAVE .. TO DISK", kami akan tetap menggunakan file konfigurasi hanya untuk membuat semuanya lebih portabel di Kubernetes. Itulah alasan kami menggunakan ConfigMaps.
Karena kita mengandalkan konfigurasi terpusat yang disimpan oleh Kubernetes ConfigMaps, ada beberapa cara untuk melakukan perubahan konfigurasi. Pertama, dengan menggunakan perintah edit kubectl:
$ kubectl edit configmap proxysql-configmapIni akan membuka konfigurasi dalam editor teks default dan Anda dapat langsung membuat perubahan dan menyimpan file teks setelah selesai. Jika tidak, buat ulang configmaps juga harus dilakukan:
$ vi proxysql.cnf # edit the configuration first
$ kubectl delete configmap proxysql-configmap
$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnfSetelah konfigurasi dimasukkan ke ConfigMap, restart pod atau container seperti yang ditunjukkan di bagian Service Control. Mengonfigurasi container melalui antarmuka admin ProxySQL (port 6032) tidak akan membuatnya tetap ada setelah pod dijadwal ulang oleh Kubernetes.
Kontrol Layanan
Karena dua container di dalam pod digabungkan dengan erat, cara terbaik untuk menerapkan perubahan konfigurasi ProxySQL adalah dengan memaksa Kubernetes melakukan penggantian pod. Pertimbangkan kami memiliki tiga pod blog sekarang setelah kami meningkatkan:
$ 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 22mGunakan perintah berikut untuk mengganti satu pod pada satu waktu:
$ kubectl get pod blog-54755cbcb5-6fnqn -n default -o yaml | kubectl replace --force -f -
pod "blog-54755cbcb5-6fnqn" deleted
pod/blog-54755cbcb5-6fnqnKemudian, verifikasi dengan yang berikut:
$ 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 2m26sAnda akan melihat pod terbaru telah dimulai ulang dengan melihat kolom AGE dan RESTART, muncul dengan nama pod yang berbeda. Ulangi langkah yang sama untuk pod yang tersisa. Jika tidak, Anda juga dapat menggunakan perintah "docker kill" untuk mematikan container ProxySQL secara manual di dalam node pekerja Kubernetes. Misalnya:
(kube-worker)$ docker kill $(docker ps | grep -i proxysql_blog | awk {'print $1'})Kubernetes kemudian akan mengganti container ProxySQL yang telah dimatikan dengan yang baru.
Pemantauan
Gunakan perintah kubectl exec untuk mengeksekusi pernyataan SQL melalui klien mysql. Misalnya, untuk memantau pencernaan kueri:
$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032
mysql> SELECT * FROM stats_mysql_query_digest;Atau dengan satu kalimat:
$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032 -e 'SELECT * FROM stats_mysql_query_digest'Dengan mengubah pernyataan SQL, Anda dapat memantau komponen ProxySQL lainnya atau melakukan tugas administrasi apa pun melalui konsol Admin ini. Sekali lagi, itu hanya akan bertahan selama masa pakai wadah ProxySQL dan tidak akan bertahan jika pod dijadwal ulang.
Pemikiran Terakhir
ProxySQL memegang peran kunci jika Anda ingin menskalakan wadah aplikasi Anda dan dan memiliki cara cerdas untuk mengakses backend database terdistribusi. Ada beberapa cara untuk men-deploy ProxySQL di Kubernetes untuk mendukung pertumbuhan aplikasi kita saat dijalankan dalam skala besar. Entri blog ini hanya mencakup salah satunya.
Dalam posting blog yang akan datang, kita akan melihat cara menjalankan ProxySQL dalam pendekatan terpusat dengan menggunakannya sebagai layanan Kubernetes.
