ProxySQL sidder normalt mellem applikations- og databaseniveauerne, i såkaldt omvendt proxy-niveau. Når dine applikationscontainere er orkestreret og administreret af Kubernetes, vil du måske bruge ProxySQL foran dine databaseservere.
I dette indlæg viser vi dig, hvordan du kører ProxySQL på Kubernetes som en hjælpebeholder i en pod. Vi kommer til at bruge Wordpress som et eksempel på applikation. Datatjenesten leveres af vores to-node MySQL-replikering, implementeret ved hjælp af ClusterControl og sidder uden for Kubernetes-netværket på en bare-metal-infrastruktur, som illustreret i følgende diagram:
ProxySQL Docker Image
I dette eksempel skal vi bruge ProxySQL Docker-billede, der vedligeholdes af Severalnines, et generelt offentligt billede bygget til multi-formålsbrug. Billedet leveres uden entrypoint-script og understøtter Galera Cluster (udover indbygget understøttelse af MySQL-replikering), hvor et ekstra script er påkrævet til sundhedstjekformål.
Grundlæggende, for at køre en ProxySQL-container, skal du blot udføre følgende kommando:
$ docker run -d -v /path/to/proxysql.cnf:/etc/proxysql.cnf severalnines/proxysqlDette billede anbefaler dig at binde en ProxySQL-konfigurationsfil til monteringspunktet /etc/proxysql.cnf, selvom du kan springe dette over og konfigurere det senere ved hjælp af ProxySQL-administrationskonsollen. Eksempler på konfigurationer findes på Docker Hub-siden eller Github-siden.
ProxySQL på Kubernetes
Design af ProxySQL-arkitekturen er et subjektivt emne og i høj grad afhængig af placeringen af applikationen og databasebeholderne samt selve ProxySQL's rolle. ProxySQL dirigerer ikke kun forespørgsler, den kan også bruges til at omskrive og cache forespørgsler. Effektive cachehits kan kræve en brugerdefineret konfiguration, der er skræddersyet specifikt til applikationsdatabasens arbejdsbyrde.
Ideelt set kan vi konfigurere ProxySQL til at blive administreret af Kubernetes med to konfigurationer:
- ProxySQL som en Kubernetes-tjeneste (centraliseret implementering).
- ProxySQL som en hjælpebeholder i en pod (distribueret implementering).
Den første mulighed er ret ligetil, hvor vi opretter en ProxySQL-pod og knytter en Kubernetes-tjeneste til den. Applikationer vil derefter oprette forbindelse til ProxySQL-tjenesten via netværk på de konfigurerede porte. Standard er 6033 for MySQL belastningsbalanceret port og 6032 for ProxySQL administrationsport. Denne implementering vil blive dækket i det kommende blogindlæg.
Den anden mulighed er lidt anderledes. Kubernetes har et koncept kaldet "pod". Du kan have en eller flere beholdere pr. pod, disse er relativt tæt koblet. En pods indhold er altid co-located og co-planlagt og kører i en delt kontekst. En pod er den mindste håndterbare containerenhed i Kubernetes.
Begge implementeringer kan let skelnes ved at se på følgende diagram:
Den primære årsag til, at pods kan have flere beholdere, er at understøtte hjælpeapplikationer, der hjælper en primær applikation. Typiske eksempler på hjælpeapplikationer er dataudtrækkere, data-pushere og proxyer. Hjælper- og primærapplikationer skal ofte kommunikere med hinanden. Dette gøres typisk gennem et delt filsystem, som vist i denne øvelse, eller gennem loopback-netværksgrænsefladen, localhost. Et eksempel på dette mønster er en webserver sammen med et hjælpeprogram, der poller et Git-lager for nye opdateringer.
Dette blogindlæg vil dække den anden konfiguration - at køre ProxySQL som en hjælpebeholder i en pod.
ProxySQL som hjælper i en pod
I denne opsætning kører vi ProxySQL som en hjælpecontainer til vores Wordpress-container. Følgende diagram illustrerer vores højniveauarkitektur:
I denne opsætning er ProxySQL-beholderen tæt forbundet med Wordpress-beholderen, og vi navngav den som "blog"-pod. Hvis der sker omplanlægning, f.eks. når Kubernetes-arbejderknudepunktet går ned, vil disse to containere altid blive omplanlagt sammen som én logisk enhed på den næste tilgængelige vært. For at holde applikationsbeholdernes indhold vedvarende på tværs af flere noder, skal vi bruge et klynget eller fjerntliggende filsystem, som i dette tilfælde er NFS.
ProxySQL-rollen er at levere et databaseabstraktionslag til applikationsbeholderen. Da vi kører en to-node MySQL-replikering som backend-databasetjenesten, er læse-skriveopdeling afgørende for at maksimere ressourceforbruget på begge MySQL-servere. ProxySQL udmærker sig ved dette og kræver minimale eller ingen ændringer af applikationen.
Der er en række andre fordele ved at køre ProxySQL i denne opsætning:
- Bring forespørgselscachekapacitet tættest på applikationslaget, der kører i Kubernetes.
- Sikker implementering ved at oprette forbindelse via ProxySQL UNIX-socket-fil. Det er som et rør, som serveren og klienterne kan bruge til at forbinde og udveksle anmodninger og data.
- Distribueret omvendt proxy-niveau med delt ingenting-arkitektur.
- Mindre netværksomkostninger på grund af implementering af "spring over netværk".
- Statsløs implementeringstilgang ved at bruge Kubernetes ConfigMaps.
Forberedelse af databasen
Opret wordpress-databasen og brugeren på masteren og tildel med korrekte rettigheder:
mysql-master> CREATE DATABASE wordpress;
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql-master> GRANT ALL PRIVILEGES ON wordpress.* TO [email protected]'%';Opret også ProxySQL-overvågningsbrugeren:
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'proxysqlpassw0rd';Genindlæs derefter bevillingstabellen:
mysql-master> FLUSH PRIVILEGES;Forberedelse af Pod'en
Kopier og indsæt nu følgende linjer i en fil kaldet blog-deployment.yml på værten, hvor kubectl er konfigureret:
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: {}YAML-filen har mange linjer, og lad os kun se den interessante del. Det første afsnit:
apiVersion: apps/v1
kind: DeploymentDen første linje er apiVersion. Vores Kubernetes-klynge kører på v1.12, så vi bør henvise til Kubernetes v1.12 API-dokumentationen og følge ressourceerklæringen i henhold til denne API. Den næste er den slags, som fortæller hvilken type ressource, vi ønsker at implementere. Deployment, Service, ReplicaSet, DaemonSet, PersistentVolume er nogle af eksemplerne.
Det næste vigtige afsnit er "beholdere". Her definerer vi alle containere, som vi gerne vil køre sammen i denne pod. Den første del er Wordpress-beholderen:
- 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: /tmpI dette afsnit fortæller vi Kubernetes om at implementere Wordpress 4.9 ved hjælp af Apache-webserver, og vi gav containeren navnet "wordpress". Vi ønsker også, at Kubernetes sender en række miljøvariabler:
- WORDPRESS_DB_HOST - Databaseværten. Da vores ProxySQL-beholder ligger i den samme Pod med Wordpress-beholderen, er det mere sikkert at bruge en ProxySQL-socket-fil i stedet. Formatet til at bruge socket-fil i Wordpress er "localhost:{sti til socket-filen}". Som standard er den placeret under mappen /tmp i ProxySQL-beholderen. Denne /tmp-sti deles mellem Wordpress- og ProxySQL-containere ved at bruge "shared-data" volumeMounts som vist længere nede. Begge containere skal montere denne diskenhed for at dele det samme indhold under /tmp-biblioteket.
- WORDPRESS_DB_USER - Angiv wordpress-databasebrugeren.
- WORDPRESS_DB_PASSWORD - Adgangskoden til WORDPRESS_DB_USER . Da vi ikke ønsker at afsløre adgangskoden i denne fil, kan vi skjule den ved hjælp af Kubernetes Secrets. Her instruerer vi Kubernetes til at læse "mysql-pass" hemmelige ressource i stedet. Hemmeligheder skal oprettes på forhånd før pod-udrulningen, som forklaret længere nede.
Vi ønsker også at udgive port 80 af containeren til slutbrugeren. Wordpress-indholdet, der er gemt inde i /var/www/html i containeren, vil blive monteret i vores vedvarende lager, der kører på NFS.
Dernæst definerer vi ProxySQL-beholderen:
- 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: proxysqlI ovenstående afsnit fortæller vi Kubernetes om at implementere en ProxySQL ved hjælp af severalnines/proxysql billedversion 1.4.12. Vi ønsker også, at Kubernetes monterer vores brugerdefinerede, præ-konfigurerede konfigurationsfil og knytter den til /etc/proxysql.cnf inde i containeren. Der vil være et volumen kaldet "shared-data", som mapper til /tmp-biblioteket for at dele med Wordpress-billedet - et midlertidigt bibliotek, der deler en pods levetid. Dette gør det muligt for ProxySQL-socket-filen (/tmp/proxysql.sock) at blive brugt af Wordpress-beholderen, når der oprettes forbindelse til databasen, og omgå TCP/IP-netværket.
Den sidste del er afsnittet "bind":
volumes:
- name: wordpress-persistent-storage
persistentVolumeClaim:
claimName: wp-pv-claim
- name: proxysql-config
configMap:
name: proxysql-configmap
- name: shared-data
emptyDir: {}Kubernetes bliver nødt til at oprette tre bind til denne pod:
- wordpress-persistent-storage - Brug PersistentVolumeClaim ressource til at kortlægge NFS-eksport til containeren til vedvarende datalagring til Wordpress-indhold.
- proxysql-config - Brug ConfigMap ressource til at kortlægge ProxySQL-konfigurationsfilen.
- delte data - Brug emptyDir ressource til at montere en delt mappe til vores containere inde i Pod'en. emptyDir ressource er en midlertidig mappe, der deler en pods levetid.
Derfor skal vi, baseret på vores YAML-definition ovenfor, forberede en række Kubernetes-ressourcer, før vi kan begynde at implementere "blog"-poden:
- Persistent Volume og PersistentVolumeClaim - For at gemme webindholdet i vores Wordpress-applikation, så når poden omlægges til en anden arbejderknude, mister vi ikke de sidste ændringer.
- Hemmeligheder - For at skjule Wordpress-databasens brugeradgangskode i YAML-filen.
- ConfigMap - For at tilknytte konfigurationsfilen til ProxySQL-container, så når den omlægges til en anden node, kan Kubernetes automatisk genmontere den igen.
PersistentVolume og PersistentVolumeClaim
En god vedvarende lagring til Kubernetes bør være tilgængelig for alle Kubernetes-noder i klyngen. Af hensyn til dette blogindlæg brugte vi NFS som PersistentVolume (PV)-udbyderen, fordi det er nemt og understøttet direkte fra boksen. NFS-serveren er placeret et sted uden for vores Kubernetes-netværk, og vi har konfigureret den til at tillade alle Kubernetes-noder med følgende linje inde i /etc/exports:
/nfs 192.168.55.*(rw,sync,no_root_squash,no_all_squash)Bemærk, at NFS-klientpakken skal installeres på alle Kubernetes-noder. Ellers ville Kubernetes ikke være i stand til at montere NFS korrekt. På alle noder:
$ sudo apt-install nfs-common #Ubuntu/Debian
$ yum install nfs-utils #RHEL/CentOSSørg også for, at målbiblioteket findes på NFS-serveren:
(nfs-server)$ mkdir /nfs/kubernetes/wordpressOpret derefter en fil kaldet wordpress-pv-pvc.yml og tilføj følgende linjer:
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: frontendI ovenstående definition vil vi gerne have, at Kubernetes allokerer 3 GB volumenplads på NFS-serveren til vores Wordpress-beholder. Vær opmærksom på produktionsbrug, NFS bør konfigureres med automatisk provisioner og lagerklasse.
Opret PV- og PVC-ressourcerne:
$ kubectl create -f wordpress-pv-pvc.ymlBekræft, om disse ressourcer er oprettet, og status skal være "Bundet":
$ 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 22hHemmeligheder
Den første er at oprette en hemmelighed, der skal bruges af Wordpress-beholderen til WORDPRESS_DB_PASSWORD miljøvariabel. Årsagen er simpelthen, fordi vi ikke ønsker at afsløre adgangskoden i klar tekst inde i YAML-filen.
Opret en hemmelig ressource kaldet mysql-pass og videregiv adgangskoden i overensstemmelse hermed:
$ kubectl create secret generic mysql-pass --from-literal=password=passw0rdBekræft, at vores hemmelighed er oprettet:
$ kubectl get secrets mysql-pass
NAME TYPE DATA AGE
mysql-pass Opaque 1 7h12mConfigMap
Vi skal også oprette en ConfigMap-ressource til vores ProxySQL-container. En Kubernetes ConfigMap-fil indeholder nøgleværdi-par af konfigurationsdata, der kan forbruges i pods eller bruges til at gemme konfigurationsdata. ConfigMaps giver dig mulighed for at afkoble konfigurationsartefakter fra billedindhold for at holde containeriserede applikationer bærbare.
Da vores databaseserver allerede kører på bare-metal-servere med et statisk værtsnavn og IP-adresse plus statisk overvågningsbrugernavn og adgangskode, vil ConfigMap-filen i dette tilfælde gemme forudkonfigurerede konfigurationsoplysninger om den ProxySQL-tjeneste, som vi ønsker at bruge.
Opret først en tekstfil kaldet proxysql.cnf og tilføj følgende linjer:
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ær ekstra opmærksom på sektionerne "mysql_servers" og "mysql_users", hvor du muligvis skal ændre værdierne, så de passer til din databaseklyngeopsætning. I dette tilfælde har vi to databaseservere, der kører i MySQL-replikering som opsummeret i følgende Topology-skærmbillede taget fra ClusterControl:
Alle skrivninger skal gå til masternoden, mens læsninger videresendes til værtsgruppe 20, som defineret under "mysql_query_rules" sektionen. Det er det grundlæggende i læse-/skriveopdeling, og vi ønsker at bruge dem helt.
Importer derefter konfigurationsfilen til ConfigMap:
$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf
configmap/proxysql-configmap createdBekræft, om ConfigMap er indlæst i Kubernetes:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 45sInstallation af Pod'en
Nu skulle vi være gode til at implementere blogpoden. Send implementeringsjobbet til Kubernetes:
$ kubectl create -f blog-deployment.ymlBekræft pod-status:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
blog-54755cbcb5-t4cb7 2/2 Running 0 100sDet skal vise 2/2 under KLAR-kolonnen, hvilket indikerer, at der er to beholdere, der kører inde i poden. Brug indstillingsflaget -c til at kontrollere Wordpress- og ProxySQL-beholderne inde i blogpoden:
$ kubectl logs blog-54755cbcb5-t4cb7 -c wordpress
$ kubectl logs blog-54755cbcb5-t4cb7 -c proxysqlFra ProxySQL-containerloggen bør du se følgende linjer:
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-værtsgruppe) må kun have én ONLINE-node (indikerer en enkelt master), og den anden vært skal være i mindst OFFLINE_HARD-status. For HID 20 forventes det at være ONLINE for alle noder (hvilket indikerer flere læste replikaer).
For at få en oversigt over implementeringen skal du bruge beskriv-flaget:
$ kubectl describe deployments blogVores blog kører nu, men vi kan ikke få adgang til den uden for Kubernetes-netværket uden at konfigurere tjenesten, som forklaret i næste afsnit.
Oprettelse af blogtjenesten
Det sidste trin er at oprette vedhæfte en service til vores pod. Dette for at sikre, at vores Wordpress blog pod er tilgængelig fra omverdenen. Opret en fil kaldet blog-svc.yml og indsæt følgende linje:
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: frontendOpret tjenesten:
$ kubectl create -f blog-svc.ymlBekræft, om tjenesten er oprettet korrekt:
[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 udgivet af blogpoden er nu kortlagt til omverdenen via port 30080. Vi kan få adgang til vores blogindlæg på http://{any_kubernetes_host}:30080/ og bør omdirigeres til Wordpress installationssiden. Hvis vi fortsætter med installationen, vil den springe databaseforbindelsesdelen over og direkte vise denne side:
Det indikerer, at vores MySQL- og ProxySQL-konfiguration er korrekt konfigureret i filen wp-config.php. Ellers vil du blive omdirigeret til databasens konfigurationsside.
Vores implementering er nu færdig.
Administration af ProxySQL-beholder inde i en Pod
Failover og gendannelse forventes at blive håndteret automatisk af Kubernetes. For eksempel, hvis Kubernetes-arbejderen går ned, vil poden blive genskabt i den næste tilgængelige node efter --pod-eviction-timeout (standard til 5 minutter). Hvis containeren går ned eller bliver dræbt, vil Kubernetes erstatte den næsten øjeblikkeligt.
Nogle almindelige administrationsopgaver forventes at være anderledes, når de kører i Kubernetes, som vist i de næste afsnit.
Skalering op og ned
I ovenstående konfiguration implementerede vi en replika i vores implementering. For at opskalere skal du blot ændre spec.replicas værdi i overensstemmelse hermed ved at bruge kubectl edit-kommandoen:
$ kubectl edit deployment blogDet åbner implementeringsdefinitionen i en standardtekstfil og ændrer simpelthen spec.replicas værdi til noget højere, for eksempel "replikaer:3". Gem derefter filen og kontroller straks udrulningsstatus ved at bruge følgende kommando:
$ 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 outPå dette tidspunkt har vi tre blogpods (Wordpress + ProxySQL) kørende samtidigt i 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 22mPå dette tidspunkt ser vores arkitektur nogenlunde sådan her ud:
Bemærk, at det kan kræve mere tilpasning end vores nuværende konfiguration at køre Wordpress problemfrit i et horisontalt skaleret produktionsmiljø (tænk på statisk indhold, sessionsstyring og andet). De er faktisk uden for rammerne af dette blogindlæg.
Nedskaleringsprocedurer ligner hinanden.
Konfigurationsstyring
Konfigurationsstyring er vigtig i ProxySQL. Det er her magien sker, hvor du kan definere dit eget sæt forespørgselsregler til at foretage forespørgselscache, firewalling og omskrivning. I modsætning til den almindelige praksis, hvor ProxySQL ville blive konfigureret via administrationskonsollen og skubbe til persistens ved at bruge "SAVE .. TO DISK", vil vi kun holde os til konfigurationsfiler for at gøre tingene mere bærbare i Kubernetes. Det er grunden til, at vi bruger ConfigMaps.
Da vi er afhængige af vores centraliserede konfiguration gemt af Kubernetes ConfigMaps, er der en række måder at udføre konfigurationsændringer på. For det første ved at bruge kommandoen kubectl edit:
$ kubectl edit configmap proxysql-configmapDet åbner konfigurationen i en standard teksteditor, og du kan direkte foretage ændringer i den og gemme tekstfilen, når den er færdig. Ellers skal du genskabe configmaps, der også skal gøre:
$ vi proxysql.cnf # edit the configuration first
$ kubectl delete configmap proxysql-configmap
$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnfNår konfigurationen er skubbet ind i ConfigMap, skal du genstarte poden eller beholderen som vist i afsnittet Servicekontrol. Konfiguration af containeren via ProxySQL admin-grænseflade (port 6032) vil ikke gøre den vedvarende efter pod-omlægning af Kubernetes.
Servicekontrol
Da de to beholdere inde i en pod er tæt forbundet, er den bedste måde at anvende ProxySQL-konfigurationsændringerne på at tvinge Kubernetes til at udskifte pod. Overvej, at vi har tre blogpods nu, efter at vi har opskaleret:
$ 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 22mBrug følgende kommando til at erstatte én pod ad gangen:
$ kubectl get pod blog-54755cbcb5-6fnqn -n default -o yaml | kubectl replace --force -f -
pod "blog-54755cbcb5-6fnqn" deleted
pod/blog-54755cbcb5-6fnqnBekræft derefter med følgende:
$ 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 2m26sDu vil bemærke, at den seneste pod er blevet genstartet ved at se på kolonnen ALDER og GENSTART, den kom med et andet podnavn. Gentag de samme trin for de resterende bælg. Ellers kan du også bruge kommandoen "docker kill" til at dræbe ProxySQL-beholderen manuelt inde i Kubernetes-arbejdernoden. For eksempel:
(kube-worker)$ docker kill $(docker ps | grep -i proxysql_blog | awk {'print $1'})Kubernetes vil derefter erstatte den dræbte ProxySQL-beholder med en ny.
Overvågning
Brug kommandoen kubectl exec til at udføre SQL-sætning via mysql-klienten. For eksempel for at overvåge forespørgselsfordøjelse:
$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032
mysql> SELECT * FROM stats_mysql_query_digest;Eller med en one-liner:
$ kubectl exec -it blog-54755cbcb5-29hqt -c proxysql -- mysql -uadmin -p -h127.0.0.1 -P6032 -e 'SELECT * FROM stats_mysql_query_digest'Ved at ændre SQL-sætningen kan du overvåge andre ProxySQL-komponenter eller udføre eventuelle administrationsopgaver via denne administrationskonsol. Igen vil det kun bestå i ProxySQL-beholderens levetid og vil ikke blive ved, hvis poden omlægges.
Sidste tanker
ProxySQL har en nøglerolle, hvis du ønsker at skalere dine applikationscontainere og have en intelligent måde at få adgang til en distribueret database backend. Der er en række måder at implementere ProxySQL på Kubernetes for at understøtte vores applikationsvækst, når den kører i stor skala. Dette blogindlæg dækker kun én af dem.
I et kommende blogindlæg skal vi se på, hvordan man kører ProxySQL i en centraliseret tilgang ved at bruge det som en Kubernetes-tjeneste.