Når man kører distribuerede databaseklynger, er det ret almindeligt at fronte dem med load balancere. Fordelene er klare - belastningsbalancering, forbindelsesfejl og afkobling af applikationsniveauet fra de underliggende databasetopologier. For mere intelligent belastningsbalancering ville en database-bevidst proxy som ProxySQL eller MaxScale være vejen at gå. I vores tidligere blog viste vi dig, hvordan du kører ProxySQL som en hjælpecontainer i Kubernetes. I dette blogindlæg viser vi dig, hvordan du implementerer ProxySQL som en Kubernetes-tjeneste. Vi bruger Wordpress som et eksempelprogram, og databasens backend kører på en MySQL-replikering med to noder, der er implementeret ved hjælp af ClusterControl. Følgende diagram illustrerer vores infrastruktur:
Da vi vil implementere en lignende opsætning som i dette tidligere blogindlæg, skal du forvente duplikering i nogle dele af blogindlægget for at holde indlægget mere læsbart.
ProxySQL på Kubernetes
Lad os starte med en lille opsummering. Design af en ProxySQL-arkitektur er et subjektivt emne og meget afhængig af placeringen af applikationen, databasebeholdere samt selve ProxySQL's rolle. 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)
Begge implementeringer kan let skelnes ved at se på følgende diagram:
Dette blogindlæg vil dække den første konfiguration - at køre ProxySQL som en Kubernetes-tjeneste. Den anden konfiguration er allerede dækket her. I modsætning til hjælpebeholdertilgangen får ProxySQL-pods at køre som en tjeneste til at leve uafhængigt af applikationerne og kan nemt skaleres og grupperes sammen ved hjælp af Kubernetes ConfigMap. Dette er bestemt en anden klyngetilgang end ProxySQL native klyngeunderstøttelse, som er afhængig af konfigurationskontrolsum på tværs af ProxySQL-instanser (a.k.a proxysql_servers). Tjek dette blogindlæg, hvis du vil lære mere om ProxySQL-klyngning, der er let med ClusterControl.
I Kubernetes gør ProxySQL's flerlagskonfigurationssystem pod-clustering mulig med ConfigMap. Der er dog en række mangler og løsninger for at få det til at fungere gnidningsløst, som det ProxySQL's native clustering-funktion gør. I øjeblikket er signalering af en pod ved ConfigMap-opdatering en funktion i værkerne. Vi vil dække dette emne meget mere detaljeret i et kommende blogindlæg.
Grundlæggende skal vi oprette ProxySQL-pods og vedhæfte en Kubernetes-tjeneste, der skal tilgås af de andre pods inden for Kubernetes-netværket eller eksternt. Programmer vil derefter oprette forbindelse til ProxySQL-tjenesten via TCP/IP-netværk på de konfigurerede porte. Standard er 6033 for MySQL belastningsbalancerede forbindelser og 6032 for ProxySQL administrationskonsol. Med mere end én replika vil forbindelserne til poden automatisk blive belastningsbalanceret af Kubernetes kube-proxy-komponent, der kører på hver Kubernetes-node.
ProxySQL som Kubernetes-tjeneste
I denne opsætning kører vi både ProxySQL og Wordpress som pods og tjenester. Følgende diagram illustrerer vores højniveauarkitektur:
I denne opsætning vil vi implementere to pods og tjenester - "wordpress" og "proxysql". Vi vil flette implementerings- og serviceerklæringen i én YAML-fil pr. applikation og administrere dem som én enhed. 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.
Implementering af ProxySQL som en tjeneste bringer et par gode ting ud over hjælpebeholdertilgangen:
- Ved brug af Kubernetes ConfigMap-tilgang kan ProxySQL grupperes med uforanderlig konfiguration.
- Kubernetes håndterer ProxySQL-gendannelse og afbalancerer forbindelserne til forekomsterne automatisk.
- Enkelt slutpunkt med implementering af Kubernetes Virtual IP-adresse kaldet ClusterIP.
- Centraliseret omvendt proxy-niveau med delt ingenting-arkitektur.
- Kan bruges med eksterne applikationer uden for Kubernetes.
Vi starter implementeringen som to replikaer til ProxySQL og tre til Wordpress for at demonstrere kørsel i skala og belastningsbalancering, som Kubernetes tilbyder.
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;ProxySQL Pod og Service Definition
Den næste er at forberede vores ProxySQL-implementering. Opret en fil kaldet proxysql-rs-svc.yml og tilføj følgende linjer:
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: frontendLad os se, hvad disse definitioner handler om. YAML består af to ressourcer kombineret i en fil, adskilt af "---" skilletegn. Den første ressource er Deployment, som vi definerer følgende specifikation:
spec:
replicas: 2
selector:
matchLabels:
app: proxysql
tier: frontend
strategy:
type: RollingUpdateOvenstående betyder, at vi gerne vil implementere to ProxySQL-pods som et ReplicaSet, der matcher containere mærket med "app=proxysql,tier=frontend". Implementeringsstrategien specificerer den strategi, der bruges til at erstatte gamle pods med nye. I denne udrulning valgte vi RollingUpdate, hvilket betyder, at pods vil blive opdateret på en rullende opdateringsmåde, én pod ad gangen.
Den næste del er containerens skabelon:
- 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-configmapI spec.templates.spec.containers.* sektion, beder vi Kubernetes om at implementere 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. De kørende pods vil udgive to porte - 6033 og 6032. Vi definerer også afsnittet "volumener", hvor vi instruerer Kubernetes om at montere ConfigMap som et volumen inde i ProxySQL pods, der skal monteres af volumeMounts.
Den anden ressource er tjenesten. En Kubernetes-tjeneste er et abstraktionslag, som definerer det logiske sæt af pods og en politik, hvormed man får adgang til dem. I dette afsnit definerer vi følgende:
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: frontendI dette tilfælde ønsker vi, at vores ProxySQL skal tilgås fra det eksterne netværk, så NodePort-typen er den valgte type. Dette vil udgive nodePort på alle Kubernetes-noder i klyngen. Rækken af gyldige porte for NodePort-ressource er 30000-32767. Vi valgte port 30033 til MySQL-belastningsbalancerede forbindelser, som er mappet til port 6033 på ProxySQL pod'erne og port 30032 for ProxySQL administrationsport kortlagt til 6032.
Derfor, baseret på vores YAML-definition ovenfor, skal vi forberede følgende Kubernetes-ressource, før vi kan begynde at implementere "proxysql"-pod'en:
- ConfigMap - Til at gemme ProxySQL-konfigurationsfilen som en volumen, så den kan monteres på flere pods og kan monteres igen, hvis poden omlægges til den anden Kubernetes-node.
Forberedelse af ConfigMap til ProxySQL
I lighed med det forrige blogindlæg vil vi bruge ConfigMap-tilgangen til at afkoble konfigurationsfilen fra containeren og også med henblik på skalerbarhed. Bemærk, at i denne opsætning anser vi vores ProxySQL-konfiguration for at være uforanderlig.
Først skal du oprette ProxySQL-konfigurationsfilen, proxysql.cnf og tilføj følgende linjer:
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ær opmærksom på admin_variables.admin_credentials variabel, hvor vi brugte ikke-standardbruger, som er "proxysql-admin". ProxySQL reserverer standard "admin"-brugeren kun til lokal forbindelse via localhost. Derfor er vi nødt til at bruge andre brugere til at få adgang til ProxySQL-instansen eksternt. Ellers vil du få følgende fejl:
ERROR 1040 (42000): User 'admin' can only connect locallyVores ProxySQL-konfiguration er baseret på vores 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 45sWordpress Pod og Service Definition
Indsæt nu følgende linjer i en fil kaldet wordpress-rs-svc.yml på værten, hvor kubectl er konfigureret:
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: frontendI lighed med vores ProxySQL-definition består YAML af to ressourcer, adskilt af "---" skilletegn kombineret i en fil. Den første er implementeringsressourcen, som vil blive implementeret som et replikasæt, som vist under afsnittet "spec.*":
spec:
replicas: 3
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: RollingUpdateDette afsnit indeholder implementeringsspecifikationen - 3 pods til start, der matcher etiketten "app=wordpress,tier=backend". Implementeringsstrategien er RollingUpdate, hvilket betyder, at Kubernetes erstatter pod'en ved at bruge rullende opdateringsmåde, det samme med vores ProxySQL-implementering.
Den næste del er sektionen "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
I dette afsnit beder vi Kubernetes om at implementere Wordpress 4.9 ved hjælp af Apache-webserver, og vi gav containeren navnet "wordpress". Containeren genstartes hver gang den er nede, uanset status. Vi ønsker også, at Kubernetes sender en række miljøvariabler:
- WORDPRESS_DB_HOST - MySQL-databaseværten. Da vi bruger ProxySQL som en tjeneste, vil tjenestenavnet være værdien af metadata.name som er "proxysql". ProxySQL lytter på port 6033 efter MySQL-belastningsbalancerede forbindelser, mens ProxySQL-administrationskonsollen er på 6032.
- WORDPRESS_DB_USER - Angiv den wordpress-databasebruger, der er blevet oprettet under afsnittet "Forberedelse af databasen".
- 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 poden 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. Vi vil bruge ressourcerne PersistentVolume og PersistentVolumeClaim til dette formål som vist under afsnittet "Forberedelse af vedvarende lagring til Wordpress".
Efter "---" pauselinjen definerer vi en anden ressource kaldet 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: frontendI denne konfiguration vil vi gerne have Kubernetes til at oprette en tjeneste kaldet "wordpress", lytte på port 30088 på alle noder (a.k.a. NodePort) til det eksterne netværk og videresende det til port 80 på alle pods mærket med "app=wordpress,tier=frontend".
Derfor skal vi, baseret på vores YAML-definition ovenfor, forberede en række Kubernetes-ressourcer, før vi kan begynde at implementere "wordpress" pod og service:
- 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.
Forberedelse af vedvarende lagring til Wordpress
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 (som vist i det første arkitekturdiagram), 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: 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: frontendI ovenstående definition beder vi Kubernetes om at allokere 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 22hForberedelse af hemmeligheder til Wordpress
Opret 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 7h12mImplementering af ProxySQL og Wordpress
Endelig kan vi begynde implementeringen. Implementer først ProxySQL efterfulgt af Wordpress:
$ kubectl create -f proxysql-rs-svc.yml
$ kubectl create -f wordpress-rs-svc.ymlVi kan derefter liste alle pods og tjenester, der er blevet oprettet under "frontend" tier:
$ 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>Ovenstående output bekræfter vores implementeringsarkitektur, hvor vi i øjeblikket har tre Wordpress-pods, der er eksponeret på port 30088 offentligt såvel som vores ProxySQL-instans, som er eksponeret på port 30033 og 30032 eksternt plus 6033 og 6032 internt.
På dette tidspunkt ser vores arkitektur nogenlunde sådan her ud:
Port 80 udgivet af Wordpress pods er nu kortlagt til omverdenen via port 30088. Vi kan få adgang til vores blogindlæg på http://{any_kubernetes_host}:30088/ 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.
ProxySQL Pods og Service Management
Failover og gendannelse forventes at blive håndteret automatisk af Kubernetes. For eksempel, hvis en Kubernetes-medarbejder 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.
Opretter forbindelse til ProxySQL
Mens ProxySQL er eksponeret eksternt på port 30033 (MySQL) og 30032 (Admin), er den også tilgængelig internt via de offentliggjorte porte, henholdsvis 6033 og 6032. For at få adgang til ProxySQL-forekomsterne inden for Kubernetes-netværket skal du bruge CLUSTER-IP eller tjenestenavnet "proxysql" som værtsværdi. I Wordpress-pod kan du f.eks. få adgang til ProxySQL-administrationskonsollen ved at bruge følgende kommando:
$ mysql -uproxysql-admin -p -hproxysql -P6032Hvis du vil oprette forbindelse eksternt, skal du bruge porten, der er defineret under nodePort-værdi, service YAML og vælge en hvilken som helst af Kubernetes-noden som værtsværdi:
$ mysql -uproxysql-admin -p -hkube3.local -P30032Det samme gælder for MySQL belastningsbalanceret forbindelse på port 30033 (ekstern) og 6033 (intern).
Skalering op og ned
Det er nemt at opskalere med Kubernetes:
$ kubectl scale deployment proxysql --replicas=5
deployment.extensions/proxysql scaledBekræft udrulningsstatus:
$ kubectl rollout status deployment proxysql
deployment "proxysql" successfully rolled outNedskalering ligner også. Her vil vi vende tilbage fra 5 til 2 replikaer:
$ kubectl scale deployment proxysql --replicas=2
deployment.extensions/proxysql scaledVi kan også se på implementeringsbegivenhederne for ProxySQL for at få et bedre billede af, hvad der er sket for denne implementering ved at bruge "beskriv"-indstillingen:
$ 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 2Forbindelserne til pod'erne bliver belastningsbalanceret automatisk af Kubernetes.
Konfigurationsændringer
En måde at foretage konfigurationsændringer på vores ProxySQL-pods er ved at versionere vores konfiguration med et andet ConfigMap-navn. For det første skal du ændre vores konfigurationsfil direkte via din foretrukne teksteditor:
$ vim /root/proxysql.cnfIndlæs det derefter i Kubernetes ConfigMap med et andet navn. I dette eksempel tilføjer vi "-v2" i ressourcenavnet:
$ kubectl create configmap proxysql-configmap-v2 --from-file=proxysql.cnfBekræft, om ConfigMap er indlæst korrekt:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 3d15h
proxysql-configmap-v2 1 19mÅbn ProxySQL-implementeringsfilen, proxysql-rs-svc.yml og ændre følgende linje under configMap-sektionen til den nye version:
volumes:
- name: proxysql-config
configMap:
name: proxysql-configmap-v2 #change this lineAnvend derefter ændringerne til vores ProxySQL-implementering:
$ kubectl apply -f proxysql-rs-svc.yml
deployment.apps/proxysql configured
service/proxysql configuredBekræft udrulningen ved at se på ReplicaSet-begivenheden ved at bruge "beskriv"-flaget:
$ 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ær opmærksom på afsnittet "Volumer" med det nye ConfigMap-navn. Du kan også se implementeringsbegivenhederne nederst i outputtet. På dette tidspunkt er vores nye konfiguration blevet indlæst i alle ProxySQL-pods, hvor Kubernetes nedskalerede ProxySQL ReplicaSet til 0 (adlyder RollingUpdate-strategien) og bringer dem tilbage til den ønskede tilstand af 2 replikaer.
Sidste tanker
Indtil dette tidspunkt har vi dækket mulig implementeringstilgang til ProxySQL i Kubernetes. At køre ProxySQL ved hjælp af Kubernetes ConfigMap åbner en ny mulighed for ProxySQL-klynger, hvor den er noget anderledes sammenlignet med den indbyggede clustering-understøttelse i ProxySQL.
I det kommende blogindlæg vil vi udforske ProxySQL Clustering ved hjælp af Kubernetes ConfigMap, og hvordan man gør det på den rigtige måde. Hold dig opdateret!