ProxySQL se běžně nachází mezi aplikační a databázovou vrstvou, v tzv. reverzní proxy vrstvě. Když jsou vaše aplikační kontejnery organizovány a spravovány Kubernetes, možná budete chtít používat ProxySQL před databázovými servery.
V tomto příspěvku vám ukážeme, jak spustit ProxySQL na Kubernetes jako pomocný kontejner v podu. Jako příklad aplikace použijeme Wordpress. Datovou službu poskytuje naše replikace MySQL se dvěma uzly, nasazená pomocí ClusterControl a umístěná mimo síť Kubernetes na infrastruktuře prostého kovu, jak ukazuje následující diagram:
Obrázek proxySQL Docker
V tomto příkladu použijeme obraz ProxySQL Docker spravovaný společností Somenines, obecný veřejný obraz vytvořený pro víceúčelové použití. Obrázek je dodáván bez vstupního skriptu a podporuje Galera Cluster (kromě vestavěné podpory replikace MySQL), kde je pro účely kontroly stavu vyžadován zvláštní skript.
V podstatě pro spuštění kontejneru ProxySQL jednoduše spusťte následující příkaz:
$ docker run -d -v /path/to/proxysql.cnf:/etc/proxysql.cnf severalnines/proxysqlTento obrázek vám doporučuje svázat konfigurační soubor ProxySQL s bodem připojení /etc/proxysql.cnf, i když to můžete přeskočit a nakonfigurovat později pomocí administrátorské konzole ProxySQL. Příklady konfigurací jsou uvedeny na stránce Docker Hub nebo na stránce Github.
ProxySQL na Kubernetes
Návrh architektury ProxySQL je subjektivní téma a velmi závisí na umístění aplikačních a databázových kontejnerů a také na roli samotného ProxySQL. ProxySQL nejen směruje dotazy, ale může být také použit k přepisování a ukládání dotazů do mezipaměti. Efektivní přístupy do mezipaměti mohou vyžadovat vlastní konfiguraci přizpůsobenou speciálně pro pracovní vytížení databáze aplikace.
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í).
První možnost je docela přímočará, kde vytvoříme ProxySQL pod a připojíme k němu službu Kubernetes. Aplikace se poté připojí ke službě ProxySQL prostřednictvím sítě na nakonfigurovaných portech. Výchozí hodnota je 6033 pro port s vyváženým zatížením MySQL a 6032 pro port administrace ProxySQL. Tomuto nasazení se budeme věnovat v nadcházejícím příspěvku na blogu.
Druhá možnost je trochu jiná. Kubernetes má koncept zvaný „pod“. Můžete mít jednu nebo více nádob na pod, tyto jsou relativně těsně spojené. Obsah podu je vždy umístěn a společně naplánován a běží ve sdíleném kontextu. Pod je nejmenší spravovatelná kontejnerová jednotka v Kubernetes.
Obě nasazení lze snadno rozlišit podle následujícího diagramu:
Primárním důvodem, proč moduly mohou mít více kontejnerů, je podpora pomocných aplikací, které pomáhají primární aplikaci. Typickými příklady pomocných aplikací jsou data puller, data pushers a proxy. Pomocné a primární aplikace spolu často potřebují komunikovat. Obvykle se to provádí prostřednictvím sdíleného souborového systému, jak je ukázáno v tomto cvičení, nebo prostřednictvím síťového rozhraní se zpětnou smyčkou, localhost. Příkladem tohoto vzoru je webový server spolu s pomocným programem, který se dotazuje na nové aktualizace v úložišti Git.
Tento blogový příspěvek se bude zabývat druhou konfigurací – spuštěním ProxySQL jako pomocného kontejneru v podu.
ProxySQL jako pomocník v podu
V tomto nastavení spouštíme ProxySQL jako pomocný kontejner k našemu kontejneru Wordpress. Následující diagram ilustruje naši architekturu na vysoké úrovni:
V tomto nastavení je kontejner ProxySQL těsně propojen s kontejnerem Wordpress a pojmenovali jsme jej jako „blogový“ pod. Pokud dojde k přeplánování, například dojde k výpadku pracovního uzlu Kubernetes, tyto dva kontejnery budou vždy přeplánovány společně jako jedna logická jednotka na dalším dostupném hostiteli. 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.
Role ProxySQL je poskytnout aplikačnímu kontejneru vrstvu abstrakce databáze. Vzhledem k tomu, že provozujeme dvouuzlovou replikaci MySQL jako backendovou databázovou službu, je rozdělení čtení a zápisu zásadní pro maximalizaci spotřeby zdrojů na obou serverech MySQL. ProxySQL v tom vyniká a vyžaduje minimální až žádné změny aplikace.
Spuštění ProxySQL v tomto nastavení má řadu dalších výhod:
- Přineste možnost ukládání dotazů do mezipaměti co nejblíže aplikační vrstvě běžící v Kubernetes.
- Zabezpečte implementaci připojením přes soubor soketu ProxySQL UNIX. Je to jako potrubí, které server a klienti mohou použít k připojení a výměně požadavků a dat.
- Vrstva distribuovaného reverzního proxy s architekturou sdíleného nic.
- Menší režie sítě díky implementaci „skip-networking“.
- Bezstavový přístup k nasazení s využitím Kubernetes ConfigMaps.
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;Příprava podu
Nyní zkopírujte a vložte následující řádky do souboru s názvem blog-deployment.yml na hostiteli, kde je nakonfigurován kubectl:
apiVersion: apps/v1
kind: Deployment
metadata:
name: blog
labels:
app: blog
spec:
replicas: 1
selector:
matchLabels:
app: blog
tier: frontend
strategy:
type: RollingUpdate
template:
metadata:
labels:
app: blog
tier: frontend
spec:
restartPolicy: Always
containers:
- image: wordpress:4.9-apache
name: wordpress
env:
- name: WORDPRESS_DB_HOST
value: localhost:/tmp/proxysql.sock
- name: WORDPRESS_DB_USER
value: wordpress
- name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-pass
key: password
ports:
- containerPort: 80
name: wordpress
volumeMounts:
- name: wordpress-persistent-storage
mountPath: /var/www/html
- name: shared-data
mountPath: /tmp
- image: severalnines/proxysql
name: proxysql
volumeMounts:
- name: proxysql-config
mountPath: /etc/proxysql.cnf
subPath: proxysql.cnf
- name: shared-data
mountPath: /tmp
volumes:
- name: wordpress-persistent-storage
persistentVolumeClaim:
claimName: wp-pv-claim
- name: proxysql-config
configMap:
name: proxysql-configmap
- name: shared-data
emptyDir: {}Soubor YAML má mnoho řádků a podívejme se pouze na tu zajímavou část. První sekce:
apiVersion: apps/v1
kind: DeploymentPrvní řádek je apiVersion. Náš cluster Kubernetes běží na verzi 1.12, takže bychom se měli podívat do dokumentace rozhraní Kubernetes v1.12 API a řídit se deklarací prostředků podle tohoto rozhraní API. Další je druh, který říká, jaký typ zdroje chceme nasadit. Deployment, Service, ReplicaSet, DaemonSet, PersistentVolume jsou některé z příkladů.
Další důležitou sekcí je sekce „kontejnery“. Zde definujeme všechny kontejnery, které bychom chtěli provozovat společně v tomto podu. První částí je kontejner 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: /tmpV této části říkáme Kubernetes, aby nasadil Wordpress 4.9 pomocí webového serveru Apache, a dali jsme kontejneru název „wordpress“. Chceme také, aby Kubernetes předával řadu proměnných prostředí:
- WORDPRESS_DB_HOST - Hostitel databáze. Vzhledem k tomu, že náš kontejner ProxySQL je umístěn ve stejném podu jako kontejner Wordpress, je bezpečnější místo toho použít soubor soketu ProxySQL. Formát pro použití soketového souboru ve Wordpressu je "localhost:{cesta k soketovému souboru}". Ve výchozím nastavení je umístěn v adresáři /tmp kontejneru ProxySQL. Tato cesta /tmp je sdílena mezi kontejnery Wordpress a ProxySQL pomocí "shared-data" volumeMounts, jak je znázorněno níže. Oba kontejnery musí připojit tento svazek, aby mohli sdílet stejný obsah v adresáři /tmp.
- WORDPRESS_DB_USER - Zadejte uživatele databáze wordpress.
- 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 kontejneru 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.
Dále definujeme ProxySQL kontejner:
- 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: proxysqlVe výše uvedené části říkáme Kubernetes, aby nasadil ProxySQL pomocí několika řádků/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. Bude existovat svazek nazvaný "shared-data", který se mapuje na adresář /tmp, aby jej bylo možné sdílet s obrazem Wordpressu - dočasným adresářem, který sdílí životnost modulu. To umožňuje použití souboru soketu ProxySQL (/tmp/proxysql.sock) kontejnerem Wordpress při připojování k databázi, čímž se obejde síť TCP/IP.
Poslední částí je sekce "svazky":
volumes:
- name: wordpress-persistent-storage
persistentVolumeClaim:
claimName: wp-pv-claim
- name: proxysql-config
configMap:
name: proxysql-configmap
- name: shared-data
emptyDir: {}Kubernetes bude muset pro tento modul vytvořit tři svazky:
- wordpress-persistent-storage – použijte PersistentVolumeClaim zdroj pro mapování exportu NFS do kontejneru pro trvalé ukládání dat pro obsah Wordpress.
- proxysql-config – Použijte ConfigMap prostředku k mapování konfiguračního souboru ProxySQL.
- shared-data – Použijte emptyDir zdroj pro připojení sdíleného adresáře pro naše kontejnery uvnitř modulu. emptyDir resource je dočasný adresář, který sdílí životnost podu.
Proto na základě naší výše uvedené definice YAML musíme připravit řadu zdrojů Kubernetes, než začneme nasazovat pod „blog“:
- 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.
- ConfigMap - Chcete-li namapovat konfigurační soubor na kontejner ProxySQL, takže když je přeplánován na jiný uzel, Kubernetes jej může automaticky znovu připojit.
PersistentVolume a PersistentVolumeClaim
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 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: 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: frontendVe výše uvedené definici bychom chtěli, aby Kubernetes alokoval 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 22hTajemství
Prvním z nich je vytvoření tajného klíče, 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 7h12mConfigMap
Potřebujeme také vytvořit prostředek ConfigMap pro náš kontejner ProxySQL. Soubor Kubernetes ConfigMap obsahuje páry klíč–hodnota konfiguračních dat, které lze spotřebovat v podech nebo použít k ukládání konfiguračních dat. ConfigMaps vám umožňují oddělit konfigurační artefakty od obsahu obrázků, aby byly kontejnerové aplikace přenosné.
Protože náš databázový server již běží na bare-metal serverech se statickým názvem hostitele a IP adresou plus statické uživatelské jméno a heslo pro monitorování, v tomto případě bude soubor ConfigMap ukládat předem nakonfigurované konfigurační informace o službě ProxySQL, kterou chceme používat.
Nejprve vytvořte textový soubor s názvem proxysql.cnf a přidejte následující řádky:
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" }
)Věnujte zvýšenou pozornost sekcím „mysql_servers“ a „mysql_users“, kde může být nutné upravit hodnoty tak, aby vyhovovaly nastavení vašeho databázového clusteru. V tomto případě máme dva databázové servery spuštěné v replikaci MySQL, 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 45sNasazení modulu
Nyní bychom měli být v pořádku nasadit blog pod. Odešlete úlohu nasazení do Kubernetes:
$ kubectl create -f blog-deployment.ymlOvěřte stav pod:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
blog-54755cbcb5-t4cb7 2/2 Running 0 100sMusí ukazovat 2/2 pod sloupcem READY, což znamená, že uvnitř podu běží dva kontejnery. Použijte parametr volby -c ke kontrole kontejnerů Wordpress a ProxySQL uvnitř blog pod:
$ kubectl logs blog-54755cbcb5-t4cb7 -c wordpress
$ kubectl logs blog-54755cbcb5-t4cb7 -c proxysqlV protokolu kontejneru ProxySQL byste měli vidět následující řádky:
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 (hostitelská skupina pro zápis) musí mít pouze jeden ONLINE uzel (označující jeden master) a druhý hostitel musí být alespoň ve stavu OFFLINE_HARD. U HID 20 se očekává, že bude ONLINE pro všechny uzly (s uvedením více replik čtení).
Chcete-li získat shrnutí nasazení, použijte příznak description:
$ kubectl describe deployments blogNáš blog nyní běží, ale nemůžeme k němu přistupovat zvenčí sítě Kubernetes bez konfigurace služby, jak je vysvětleno v další části.
Vytvoření služby blogu
Posledním krokem je vytvoření připojení služby k našemu modulu. Tím se zajistí, že náš blogový modul Wordpress bude přístupný z vnějšího světa. Vytvořte soubor s názvem blog-svc.yml a vložte následující řádek:
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: frontendVytvořte službu:
$ kubectl create -f blog-svc.ymlOvěřte, zda je služba vytvořena správně:
[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 publikovaný pod blogem je nyní namapován na vnější svět prostřednictvím portu 30080. K našemu příspěvku na blogu máme přístup na adrese http://{any_kubernetes_host}:30080/ 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.
Správa kontejneru ProxySQL uvnitř podu
Očekává se, že převzetí služeb při selhání a obnovení bude automaticky zpracováno Kubernetes. Pokud například pracovník Kubernetes selže, pod bude znovu vytvořen 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.
Zvětšení a zmenšení
Ve výše uvedené konfiguraci jsme v našem nasazení nasazovali jednu repliku. Chcete-li zvětšit, jednoduše změňte spec.replicas hodnotu odpovídajícím způsobem pomocí příkazu kubectl edit:
$ kubectl edit deployment blogOtevře se definice nasazení ve výchozím textovém souboru a jednoduše se změní spec.replicas hodnotu na něco vyššího, například „repliky:3“. Poté soubor uložte a okamžitě zkontrolujte stav zavedení pomocí následujícího příkazu:
$ 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 outV tuto chvíli máme tři blogové moduly (Wordpress + ProxySQL) běžící současně v 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 22mV tuto chvíli naše architektura vypadá asi takto:
Uvědomte si, že může vyžadovat více přizpůsobení než naše současná konfigurace, aby Wordpress fungoval hladce v horizontálním produkčním prostředí (přemýšlejte o statickém obsahu, správě relací a dalších). To je ve skutečnosti nad rámec tohoto blogového příspěvku.
Postupy zmenšení jsou podobné.
Správa konfigurace
Správa konfigurace je v ProxySQL důležitá. To je místo, kde se stane kouzlo, kde můžete definovat vlastní sadu pravidel dotazů pro ukládání dotazů do mezipaměti, firewallování a přepisování. Na rozdíl od běžné praxe, kdy by se ProxySQL konfigurovalo přes administrátorskou konzoli a tlačilo do persistence pomocí „ULOŽIT .. NA DISK“, zůstaneme u konfiguračních souborů pouze proto, aby bylo možné věci v Kubernetes lépe přenášet. To je důvod, proč používáme ConfigMaps.
Protože se spoléháme na naši centralizovanou konfiguraci uloženou v Kubernetes ConfigMaps, existuje řada způsobů, jak provést změny konfigurace. Nejprve pomocí příkazu kubectl edit:
$ kubectl edit configmap proxysql-configmapOtevře se konfigurace ve výchozím textovém editoru a můžete v ní přímo provádět změny a po dokončení uložit textový soubor. V opačném případě znovu vytvořte configmaps, které by také měly dělat:
$ vi proxysql.cnf # edit the configuration first
$ kubectl delete configmap proxysql-configmap
$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnfPo vložení konfigurace do ConfigMap restartujte modul nebo kontejner, jak je znázorněno v části Řízení služeb. Konfigurace kontejneru prostřednictvím administrátorského rozhraní ProxySQL (port 6032) jej neučiní trvalým po přeplánování modulu Kubernetes.
Řízení služeb
Vzhledem k tomu, že dva kontejnery uvnitř pod jsou těsně propojeny, nejlepším způsobem, jak aplikovat změny konfigurace ProxySQL, je přinutit Kubernetes provést výměnu podu. Zvažte, že po rozšíření máme nyní tři blogové moduly:
$ 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 22mPomocí následujícího příkazu vyměňte jeden modul po druhém:
$ kubectl get pod blog-54755cbcb5-6fnqn -n default -o yaml | kubectl replace --force -f -
pod "blog-54755cbcb5-6fnqn" deleted
pod/blog-54755cbcb5-6fnqnPoté ověřte pomocí následujícího:
$ 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 2m26sVšimněte si, že nejnovější modul byl restartován, když se podíváte na sloupec AGE a RESTART, kde je uveden jiný název modulu. Opakujte stejné kroky pro zbývající lusky. Jinak můžete také použít příkaz "docker kill" k ručnímu ukončení kontejneru ProxySQL uvnitř pracovního uzlu Kubernetes. Například:
(kube-worker)$ docker kill $(docker ps | grep -i proxysql_blog | awk {'print $1'})Kubernetes poté nahradí zabitý ProxySQL kontejner novým.
Monitorování
Použijte příkaz kubectl exec k provedení příkazu SQL prostřednictvím klienta mysql. Chcete-li například sledovat zpracování dotazů:
$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032
mysql> SELECT * FROM stats_mysql_query_digest;Nebo s jednou vložkou:
$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032 -e 'SELECT * FROM stats_mysql_query_digest'Změnou příkazu SQL můžete sledovat další komponenty ProxySQL nebo provádět jakékoli administrativní úkoly prostřednictvím této administrátorské konzole. Opět bude přetrvávat pouze během životnosti kontejneru ProxySQL a nezůstane zachováno, pokud bude modul přeplánován.
Poslední myšlenky
ProxySQL má klíčovou roli, pokud chcete škálovat své aplikační kontejnery a mít inteligentní způsob přístupu k distribuovanému databázovému backendu. Existuje řada způsobů, jak nasadit ProxySQL na Kubernetes, abychom podpořili růst našich aplikací při běhu ve velkém. Tento blogový příspěvek se týká pouze jednoho z nich.
V nadcházejícím příspěvku na blogu se podíváme na to, jak spouštět ProxySQL centralizovaným přístupem pomocí jeho použití jako služby Kubernetes.