Při provozování distribuovaných databázových clusterů je zcela běžné, že je nahradíte nástroji pro vyrovnávání zatížení. Výhody jsou jasné – load balancing, failover připojení a oddělení aplikační vrstvy od podkladových databázových topologií. Pro inteligentnější vyvažování zátěže by byl správným řešením proxy server s databází, jako je ProxySQL nebo MaxScale. V našem předchozím blogu jsme vám ukázali, jak spustit ProxySQL jako pomocný kontejner v Kubernetes. V tomto příspěvku na blogu vám ukážeme, jak nasadit ProxySQL jako službu Kubernetes. Jako příklad aplikace použijeme Wordpress a backend databáze běží na dvouuzlovém MySQL Replication nasazeném pomocí ClusterControl. Následující diagram znázorňuje naši infrastrukturu:
Protože se chystáme nasadit podobné nastavení jako v tomto předchozím blogovém příspěvku, počítejte s duplicitou v některých částech blogového příspěvku, aby byl příspěvek čitelnější.
ProxySQL na Kubernetes
Začněme malou rekapitulací. Návrh architektury ProxySQL je subjektivní téma a velmi závisí na umístění aplikace, databázových kontejnerech a také na roli samotného ProxySQL. V ideálním případě můžeme nakonfigurovat ProxySQL tak, aby byl spravován Kubernetes, se dvěma konfiguracemi:
- ProxySQL jako služba Kubernetes (centralizované nasazení)
- ProxySQL jako pomocný kontejner v podu (distribuované nasazení)
Obě nasazení lze snadno rozlišit podle následujícího diagramu:
Tento blogový příspěvek se bude týkat první konfigurace – spuštění ProxySQL jako služby Kubernetes. Druhá konfigurace je zde již popsána. Na rozdíl od přístupu pomocných kontejnerů umožňuje běh jako služba ProxySQL pody žít nezávisle na aplikacích a lze je snadno škálovat a klastrovat společně pomocí Kubernetes ConfigMap. Toto je rozhodně odlišný přístup ke shlukování než podpora nativního shlukování ProxySQL, která se spoléhá na kontrolní součet konfigurace napříč instancemi ProxySQL (také znám jako proxysql_servers). Podívejte se na tento blogový příspěvek, pokud se chcete dozvědět o clusteringu ProxySQL, který je s ClusterControl snadný.
V Kubernetes vícevrstvý konfigurační systém ProxySQL umožňuje shlukování podů pomocí ConfigMap. Existuje však řada nedostatků a řešení, aby to fungovalo hladce, jako to dělá nativní funkce clusteringu ProxySQL. V současné době je signalizace modulu při aktualizaci ConfigMap funkcí, na které se pracuje. Tomuto tématu se budeme věnovat mnohem podrobněji v nadcházejícím příspěvku na blogu.
V zásadě musíme vytvořit ProxySQL pody a připojit službu Kubernetes, aby k ní měly přístup ostatní pody v rámci sítě Kubernetes nebo externě. Aplikace se poté připojí ke službě ProxySQL prostřednictvím sítě TCP/IP na nakonfigurovaných portech. Výchozí hodnota je 6033 pro připojení s vyváženým zatížením MySQL a 6032 pro konzolu pro správu ProxySQL. S více než jednou replikou budou připojení k podu automaticky vyrovnávána zátěž pomocí komponenty Kubernetes kube-proxy běžící na každém uzlu Kubernetes.
ProxySQL jako služba Kubernetes
V tomto nastavení spouštíme ProxySQL i Wordpress jako moduly a služby. Následující diagram ilustruje naši architekturu na vysoké úrovni:
V tomto nastavení nasadíme dva pody a služby – „wordpress“ a „proxysql“. Sloučíme prohlášení o nasazení a službě do jednoho souboru YAML na aplikaci a budeme je spravovat jako jeden celek. Aby byl obsah aplikačních kontejnerů trvalý na více uzlech, musíme použít klastrovaný nebo vzdálený souborový systém, kterým je v tomto případě NFS.
Nasazení ProxySQL jako služby přináší oproti přístupu pomocného kontejneru několik dobrých věcí:
- Pomocí přístupu Kubernetes ConfigMap lze ProxySQL klastrovat s neměnnou konfigurací.
- Kubernetes automaticky zajišťuje obnovu ProxySQL a vyrovnává připojení k instancím.
- Jeden koncový bod s implementací virtuální IP adresy Kubernetes s názvem ClusterIP.
- Centralizovaná vrstva reverzního proxy s architekturou sdíleného nic.
- Lze použít s externími aplikacemi mimo Kubernetes.
Zahájíme nasazení jako dvě repliky pro ProxySQL a tři pro Wordpress, abychom předvedli běh ve velkém měřítku a možnosti vyvažování zátěže, které Kubernetes nabízí.
Příprava databáze
Vytvořte databázi wordpress a uživatele na hlavním serveru a přiřaďte jim správná oprávnění:
mysql-master> CREATE DATABASE wordpress;
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql-master> GRANT ALL PRIVILEGES ON wordpress.* TO [email protected]'%';Vytvořte také uživatele monitorování ProxySQL:
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'proxysqlpassw0rd';Poté znovu načtěte tabulku grantů:
mysql-master> FLUSH PRIVILEGES;ProxySQL Pod a definice služby
Dalším krokem je příprava nasazení ProxySQL. Vytvořte soubor s názvem proxysql-rs-svc.yml a přidejte následující řádky:
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: frontendPodívejme se, o čem tyto definice jsou. YAML se skládá ze dvou zdrojů spojených v souboru, oddělených oddělovačem "---". Prvním zdrojem je Deployment, který definujeme následující specifikací:
spec:
replicas: 2
selector:
matchLabels:
app: proxysql
tier: frontend
strategy:
type: RollingUpdateVýše uvedené znamená, že bychom chtěli nasadit dva moduly ProxySQL jako sadu ReplicaSet, která odpovídá kontejnerům označeným "app=proxysql,tier=frontend". Strategie nasazení určuje strategii použitou k nahrazení starých modulů novými. V tomto nasazení jsme zvolili RollingUpdate, což znamená, že moduly budou aktualizovány způsobem průběžných aktualizací, jeden modul po druhém.
Další částí je šablona kontejneru:
- 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-configmapV spec.templates.spec.containers.* v sekci říkáme Kubernetes, aby nasadil ProxySQL pomocí několika nin/proxysql verze obrázku 1.4.12. Chceme také, aby Kubernetes připojil náš vlastní, předem nakonfigurovaný konfigurační soubor a namapoval jej na /etc/proxysql.cnf uvnitř kontejneru. Spuštěné moduly budou publikovat dva porty – 6033 a 6032. Definujeme také sekci „volumes“, kde dáváme Kubernetes pokyn, aby připojil ConfigMap jako svazek uvnitř ProxySQL podů, který má být připojen pomocí volumeMounts.
Druhým zdrojem je služba. Služba Kubernetes je abstraktní vrstva, která definuje logickou sadu podů a zásady, pomocí kterých k nim lze přistupovat. V této části definujeme následující:
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: frontendV tomto případě chceme, aby naše ProxySQL bylo přístupné z externí sítě, takže typ NodePort je zvoleným typem. Tím se publikuje nodePort na všech uzlech Kubernetes v clusteru. Rozsah platných portů pro prostředek NodePort je 30000-32767. Zvolili jsme port 30033 pro připojení s vyváženým zatížením MySQL, který je mapován na port 6033 podů ProxySQL a port 30032 pro administrační port ProxySQL mapovaný na 6032.
Proto na základě naší výše uvedené definice YAML musíme připravit následující zdroj Kubernetes, než začneme nasazovat pod „proxysql“:
- ConfigMap – Pro uložení konfiguračního souboru ProxySQL jako svazku, aby jej bylo možné připojit k více modulům a znovu jej připojit, pokud je modul přeplánován na jiný uzel Kubernetes.
Příprava ConfigMap pro ProxySQL
Podobně jako v předchozím příspěvku na blogu použijeme přístup ConfigMap k oddělení konfiguračního souboru od kontejneru a také pro účely škálovatelnosti. Vezměte na vědomí, že v tomto nastavení považujeme konfiguraci ProxySQL za neměnnou.
Nejprve vytvořte konfigurační soubor ProxySQL, proxysql.cnf a přidejte následující řádky:
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
}
)Věnujte pozornost admin_variables.admin_credentials proměnná, kde jsme použili jiného než výchozího uživatele, což je "proxysql-admin". ProxySQL si vyhrazuje výchozího uživatele „admin“ pro lokální připojení pouze přes localhost. Pro vzdálený přístup k instanci ProxySQL tedy musíme použít jiné uživatele. Jinak by se zobrazila následující chyba:
ERROR 1040 (42000): User 'admin' can only connect locallyNaše konfigurace ProxySQL je založena na našich dvou databázových serverech běžících v MySQL Replication, jak je shrnuto na následujícím snímku obrazovky topologie převzatém z ClusterControl:
Všechny zápisy by měly směřovat do hlavního uzlu, zatímco čtení jsou předávána hostitelské skupině 20, jak je definováno v části "mysql_query_rules". To je základ rozdělení čtení/zápisu a my je chceme využít úplně.
Poté importujte konfigurační soubor do ConfigMap:
$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf
configmap/proxysql-configmap createdOvěřte, zda je ConfigMap načtena do Kubernetes:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 45sPod a definice služby Wordpress
Nyní vložte následující řádky do souboru s názvem wordpress-rs-svc.yml na hostiteli, kde je nakonfigurován 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: frontendPodobně jako naše definice ProxySQL se YAML skládá ze dvou zdrojů oddělených oddělovačem "---" spojeným v souboru. Prvním z nich je prostředek Deployment, který bude nasazen jako ReplicaSet, jak je uvedeno v části "spec.*":
spec:
replicas: 3
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: RollingUpdateTato část obsahuje specifikaci nasazení – 3 moduly pro začátek, které odpovídají štítku „app=wordpress,tier=backend“. Strategií nasazení je RollingUpdate, což znamená, že způsob, jakým Kubernetes nahradí modul, je pomocí postupné aktualizace, stejně jako u našeho nasazení ProxySQL.
Další částí je sekce "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
V této části říkáme Kubernetes, aby nasadil Wordpress 4.9 pomocí webového serveru Apache, a dali jsme kontejneru název „wordpress“. Kontejner bude restartován pokaždé, když bude mimo provoz, bez ohledu na stav. Chceme také, aby Kubernetes předával řadu proměnných prostředí:
- WORDPRESS_DB_HOST - Hostitel databáze MySQL. Protože používáme ProxySQL jako službu, název služby bude mít hodnotu metadata.name což je "proxysql". ProxySQL naslouchá na portu 6033 pro připojení s vyváženým zatížením MySQL, zatímco konzola pro správu ProxySQL je na 6032.
- WORDPRESS_DB_USER - Zadejte uživatele databáze wordpress, který byl vytvořen v části "Příprava databáze".
- WORDPRESS_DB_PASSWORD – Heslo pro WORDPRESS_DB_USER . Protože v tomto souboru nechceme odhalit heslo, můžeme ho skrýt pomocí Kubernetes Secrets. Zde dáváme pokyn Kubernetes, aby si místo toho přečetl tajný zdroj „mysql-pass“. Tajemství musí být vytvořeno předem před nasazením modulu, jak je vysvětleno níže.
Chceme také zveřejnit port 80 podu pro koncového uživatele. Obsah Wordpressu uložený uvnitř /var/www/html v kontejneru bude připojen do našeho trvalého úložiště běžícího na NFS. Pro tento účel použijeme zdroje PersistentVolume a PersistentVolumeClaim, jak je uvedeno v části „Příprava trvalého úložiště pro Wordpress“.
Za zalomením "---" definujeme další zdroj s názvem 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: frontendV této konfiguraci bychom chtěli, aby Kubernetes vytvořil službu s názvem „wordpress“, naslouchal na portu 30088 na všech uzlech (aka NodePort) do externí sítě a přeposlal ji na port 80 na všech podech označených „app=wordpress,tier=“. frontend".
Proto na základě naší výše uvedené definice YAML musíme připravit řadu zdrojů Kubernetes, než začneme nasazovat modul a službu „wordpress“:
- PersistentVolume a PersistentVolumeClaim - Chcete-li ukládat webový obsah naší aplikace Wordpress, takže když je modul přeplánován na jiný pracovní uzel, nepřijdeme o poslední změny.
- Tajemství - Chcete-li skrýt heslo uživatele databáze Wordpress v souboru YAML.
Příprava trvalého úložiště pro Wordpress
Dobré trvalé úložiště pro Kubernetes by mělo být dostupné pro všechny uzly Kubernetes v clusteru. V zájmu tohoto blogového příspěvku jsme jako poskytovatele PersistentVolume (PV) použili NFS, protože je to snadné a podporované ihned po vybalení. Server NFS se nachází někde mimo naši síť Kubernetes (jak je znázorněno na prvním schématu architektury) a nakonfigurovali jsme jej tak, aby umožňoval všechny uzly Kubernetes s následujícím řádkem v /etc/exports:
/nfs 192.168.55.*(rw,sync,no_root_squash,no_all_squash)Vezměte na vědomí, že balíček klienta NFS musí být nainstalován na všech uzlech Kubernetes. Jinak by Kubernetes nemohl správně připojit NFS. Na všech uzlech:
$ sudo apt-install nfs-common #Ubuntu/Debian
$ yum install nfs-utils #RHEL/CentOSTaké se ujistěte, že na serveru NFS existuje cílový adresář:
(nfs-server)$ mkdir /nfs/kubernetes/wordpressPoté vytvořte soubor s názvem wordpress-pv-pvc.yml a přidejte následující řádky:
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: frontendVe výše uvedené definici říkáme Kubernetes, aby přidělil 3 GB prostoru na svazku na serveru NFS pro náš kontejner Wordpress. Při produkčním použití by měl být NFS nakonfigurován s automatickým zřizováním a třídou úložiště.
Vytvořte zdroje PV a PVC:
$ kubectl create -f wordpress-pv-pvc.ymlOvěřte, zda jsou tyto zdroje vytvořeny a stav musí být "Bound":
$ 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 22hPříprava tajemství pro Wordpress
Vytvořte tajný klíč, který bude kontejner Wordpress používat pro WORDPRESS_DB_PASSWORD proměnná prostředí. Důvodem je jednoduše to, že nechceme v souboru YAML zveřejňovat heslo jako prostý text.
Vytvořte tajný zdroj nazvaný mysql-pass a předejte mu heslo:
$ kubectl create secret generic mysql-pass --from-literal=password=passw0rdOvěřte, že je naše tajemství vytvořeno:
$ kubectl get secrets mysql-pass
NAME TYPE DATA AGE
mysql-pass Opaque 1 7h12mNasazení ProxySQL a Wordpress
Konečně můžeme začít s nasazením. Nejprve nasaďte ProxySQL a poté Wordpress:
$ kubectl create -f proxysql-rs-svc.yml
$ kubectl create -f wordpress-rs-svc.ymlPoté můžeme vypsat všechny moduly a služby, které byly vytvořeny na úrovni „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>Výše uvedený výstup ověřuje naši architekturu nasazení, kde aktuálně máme tři moduly Wordpress, veřejně přístupné na portu 30088 a také naši instanci ProxySQL, která je vystavena na portech 30033 a 30032 externě plus 6033 a 6032 interně.
V tuto chvíli naše architektura vypadá asi takto:
Port 80 publikovaný moduly Wordpress je nyní namapován na vnější svět prostřednictvím portu 30088. Náš příspěvek na blogu máme na adrese http://{any_kubernetes_host}:30088/ a měli bychom být přesměrováni na stránku instalace Wordpressu. Pokud bychom pokračovali v instalaci, přeskočilo by to část s připojením k databázi a přímo zobrazilo tuto stránku:
Znamená to, že naše konfigurace MySQL a ProxySQL je správně nakonfigurována v souboru wp-config.php. V opačném případě byste byli přesměrováni na konfigurační stránku databáze.
Naše nasazení je nyní dokončeno.
ProxySQL Pods a správa služeb
Očekává se, že převzetí služeb při selhání a obnovení bude automaticky zpracováno Kubernetes. Pokud například dojde k výpadku pracovníka Kubernetes, pod se znovu vytvoří v dalším dostupném uzlu po --pod-eviction-timeout (výchozí hodnota je 5 minut). Pokud se kontejner zhroutí nebo je zabit, Kubernetes jej téměř okamžitě nahradí.
Očekává se, že některé běžné úlohy správy se při spuštění v rámci Kubernetes budou lišit, jak je ukázáno v dalších částech.
Připojování k ProxySQL
Zatímco ProxySQL je vystaven externě na portu 30033 (MySQL) a 30032 (Admin), je také přístupný interně prostřednictvím publikovaných portů, 6033 a 6032. Pro přístup k instancím ProxySQL v síti Kubernetes tedy použijte CLUSTER-IP nebo název služby „proxysql“ jako hodnotu hostitele. Například v rámci Wordpress pod můžete přistupovat k administrátorské konzoli ProxySQL pomocí následujícího příkazu:
$ mysql -uproxysql-admin -p -hproxysql -P6032Pokud se chcete připojit externě, použijte port definovaný pod hodnotou nodePort pro službu YAML a jako hodnotu hostitele vyberte libovolný uzel Kubernetes:
$ mysql -uproxysql-admin -p -hkube3.local -P30032Totéž platí pro připojení s vyváženým zatížením MySQL na portu 30033 (externí) a 6033 (interní).
Zvětšení a zmenšení
S Kubernetes je škálování snadné:
$ kubectl scale deployment proxysql --replicas=5
deployment.extensions/proxysql scaledOvěřte stav zavádění:
$ kubectl rollout status deployment proxysql
deployment "proxysql" successfully rolled outSnížení je také podobné. Zde se chceme vrátit zpět z 5 na 2 repliky:
$ kubectl scale deployment proxysql --replicas=2
deployment.extensions/proxysql scaledMůžeme se také podívat na události nasazení pro ProxySQL, abychom získali lepší obrázek o tom, co se stalo při tomto nasazení, pomocí možnosti „popsat“:
$ 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 2Kubernetes automaticky vyrovnává zatížení připojení k modulům.
Změny konfigurace
Jedním ze způsobů, jak provést změny konfigurace na našich modulech ProxySQL, je verzování naší konfigurace pomocí jiného názvu ConfigMap. Nejprve upravte náš konfigurační soubor přímo prostřednictvím vašeho oblíbeného textového editoru:
$ vim /root/proxysql.cnfPoté jej nahrajte do Kubernetes ConfigMap s jiným názvem. V tomto příkladu připojíme "-v2" k názvu zdroje:
$ kubectl create configmap proxysql-configmap-v2 --from-file=proxysql.cnfOvěřte, zda je ConfigMap správně načtena:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 3d15h
proxysql-configmap-v2 1 19mOtevřete soubor nasazení ProxySQL, proxysql-rs-svc.yml a změňte následující řádek v části configMap na novou verzi:
volumes:
- name: proxysql-config
configMap:
name: proxysql-configmap-v2 #change this linePoté aplikujte změny na naše nasazení ProxySQL:
$ kubectl apply -f proxysql-rs-svc.yml
deployment.apps/proxysql configured
service/proxysql configuredOvěřte zavedení pomocí pohledu na událost ReplicaSet pomocí příznaku "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 0Věnujte pozornost sekci "Volumes" s novým názvem ConfigMap. Události nasazení můžete také vidět ve spodní části výstupu. V tuto chvíli byla naše nová konfigurace nahrána do všech modulů ProxySQL, kde Kubernetes zmenšil ProxySQL ReplicaSet na 0 (v souladu se strategií RollingUpdate) a vrátil je zpět do požadovaného stavu 2 replik.
Poslední myšlenky
Až do tohoto okamžiku jsme se zabývali možným přístupem k nasazení ProxySQL v Kubernetes. Spuštění ProxySQL s pomocí Kubernetes ConfigMap otevírá novou možnost clusterování ProxySQL, kde je poněkud odlišné ve srovnání s nativní podporou clusterů zabudovanou v ProxySQL.
V nadcházejícím blogovém příspěvku prozkoumáme ProxySQL Clustering pomocí Kubernetes ConfigMap a jak to udělat správným způsobem. Zůstaňte naladěni!