När man kör distribuerade databaskluster är det ganska vanligt att fronta dem med lastbalanserare. Fördelarna är tydliga - lastbalansering, anslutningsfel och frikoppling av applikationsnivån från de underliggande databastopologierna. För mer intelligent lastbalansering skulle en databasmedveten proxy som ProxySQL eller MaxScale vara rätt väg att gå. I vår tidigare blogg visade vi hur du kör ProxySQL som en hjälparcontainer i Kubernetes. I det här blogginlägget visar vi dig hur du distribuerar ProxySQL som en Kubernetes-tjänst. Vi kommer att använda Wordpress som ett exempelprogram och databasens backend körs på en MySQL-replikering med två noder som distribueras med ClusterControl. Följande diagram illustrerar vår infrastruktur:
Eftersom vi kommer att distribuera en liknande inställning som i det här tidigare blogginlägget, förvänta dig dubbelarbete i vissa delar av blogginlägget för att hålla inlägget mer läsbart.
ProxySQL på Kubernetes
Låt oss börja med en liten sammanfattning. Att designa en ProxySQL-arkitektur är ett subjektivt ämne och i hög grad beroende av placeringen av applikationen, databasbehållare samt rollen som ProxySQL själv. Helst kan vi konfigurera ProxySQL för att hanteras av Kubernetes med två konfigurationer:
- ProxySQL som en Kubernetes-tjänst (centraliserad distribution)
- ProxySQL som en hjälpbehållare i en pod (distribuerad distribution)
Båda distributionerna kan enkelt särskiljas genom att titta på följande diagram:
Det här blogginlägget kommer att täcka den första konfigurationen - att köra ProxySQL som en Kubernetes-tjänst. Den andra konfigurationen täcks redan här. I motsats till hjälpbehållarmetoden gör körning som en tjänst att ProxySQL-poddar lever oberoende av applikationerna och kan enkelt skalas och klustras ihop med hjälp av Kubernetes ConfigMap. Detta är definitivt en annan klustringsmetod än ProxySQL inbyggt klustringsstöd som förlitar sig på konfigurationskontrollsumma över ProxySQL-instanser (a.k.a proxysql_servers). Kolla in det här blogginlägget om du vill lära dig mer om ProxySQL-klustring på ett enkelt sätt med ClusterControl.
I Kubernetes gör ProxySQL:s flerskiktskonfigurationssystem pod-klustring möjlig med ConfigMap. Det finns dock ett antal brister och lösningar för att få det att fungera smidigt som vad ProxySQL:s inbyggda klustringsfunktion gör. Just nu är det en funktion på gång att signalera en pod vid uppdatering av ConfigMap. Vi kommer att ta upp det här ämnet mycket mer detaljerat i ett kommande blogginlägg.
I grund och botten måste vi skapa ProxySQL-poddar och bifoga en Kubernetes-tjänst som ska nås av de andra podarna inom Kubernetes-nätverket eller externt. Applikationer kommer sedan att ansluta till ProxySQL-tjänsten via TCP/IP-nätverk på de konfigurerade portarna. Standard är 6033 för MySQL belastningsbalanserade anslutningar och 6032 för ProxySQL administrationskonsol. Med mer än en replik kommer anslutningarna till podden att lastbalanseras automatiskt av Kubernetes kube-proxy-komponent som körs på varje Kubernetes-nod.
ProxySQL som Kubernetes-tjänst
I den här installationen kör vi både ProxySQL och Wordpress som pods och tjänster. Följande diagram illustrerar vår högnivåarkitektur:
I den här installationen kommer vi att distribuera två pods och tjänster - "wordpress" och "proxysql". Vi kommer att slå samman Deployment och Service-deklaration i en YAML-fil per applikation och hantera dem som en enhet. För att hålla programbehållarnas innehåll beständigt över flera noder måste vi använda ett klustrade eller fjärranslutna filsystem, som i det här fallet är NFS.
Att implementera ProxySQL som en tjänst ger ett par bra saker över hjälpbehållarmetoden:
- Med Kubernetes ConfigMap-metoden kan ProxySQL klustras med oföränderlig konfiguration.
- Kubernetes hanterar ProxySQL-återställning och balanserar anslutningarna till instanserna automatiskt.
- En enda slutpunkt med implementering av Kubernetes virtuella IP-adress som kallas ClusterIP.
- Centraliserad omvänd proxynivå med delad ingenting-arkitektur.
- Kan användas med externa applikationer utanför Kubernetes.
Vi kommer att starta implementeringen som två repliker för ProxySQL och tre för Wordpress för att demonstrera körning i skala och lastbalanserande funktioner som Kubernetes erbjuder.
Förbereder databasen
Skapa wordpress-databasen och användaren på mastern och tilldela med rätt behörighet:
mysql-master> CREATE DATABASE wordpress;
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql-master> GRANT ALL PRIVILEGES ON wordpress.* TO [email protected]'%';Skapa också ProxySQL-övervakningsanvändaren:
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'proxysqlpassw0rd';Ladda sedan om bidragstabellen:
mysql-master> FLUSH PRIVILEGES;ProxySQL Pod och Service Definition
Nästa är att förbereda vår ProxySQL-distribution. Skapa en fil som heter proxysql-rs-svc.yml och lägg till följande rader:
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: frontendLåt oss se vad dessa definitioner handlar om. YAML består av två resurser kombinerade i en fil, åtskilda av "---" avgränsare. Den första resursen är Deployment, som vi definierar följande specifikation:
spec:
replicas: 2
selector:
matchLabels:
app: proxysql
tier: frontend
strategy:
type: RollingUpdateOvanstående betyder att vi skulle vilja distribuera två ProxySQL-pods som en ReplicaSet som matchar behållare märkta med "app=proxysql,tier=frontend". Distributionsstrategin specificerar strategin som används för att ersätta gamla pods med nya. I den här implementeringen valde vi RollingUpdate vilket innebär att poddarna kommer att uppdateras på ett rullande uppdateringssätt, en pod i taget.
Nästa del är behållarens mall:
- 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.* avsnitt, säger vi åt Kubernetes att distribuera ProxySQL med severalnines/proxysql bildversion 1.4.12. Vi vill också att Kubernetes ska montera vår anpassade, förkonfigurerade konfigurationsfil och mappa den till /etc/proxysql.cnf inuti behållaren. De körande poddarna kommer att publicera två portar - 6033 och 6032. Vi definierar också avsnittet "volymer", där vi instruerar Kubernetes att montera ConfigMap som en volym inuti ProxySQL-podarna som ska monteras av volumeMounts.
Den andra resursen är tjänsten. En Kubernetes-tjänst är ett abstraktionslager som definierar den logiska uppsättningen av pods och en policy för åtkomst till dem. I det här avsnittet definierar vi följande:
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 det här fallet vill vi att vår ProxySQL ska nås från det externa nätverket, så NodePort-typen är den valda typen. Detta kommer att publicera nodePorten på alla Kubernetes-noder i klustret. Utbudet av giltiga portar för NodePort-resursen är 30000-32767. Vi valde port 30033 för MySQL-lastbalanserade anslutningar som är mappad till port 6033 för ProxySQL-podarna och port 30032 för ProxySQL Administration-port mappad till 6032.
Därför, baserat på vår YAML-definition ovan, måste vi förbereda följande Kubernetes-resurs innan vi kan börja distribuera "proxysql"-podden:
- ConfigMap - För att lagra ProxySQL-konfigurationsfilen som en volym så att den kan monteras på flera poddar och kan monteras om igen om podden schemaläggs om till den andra Kubernetes-noden.
Förbereder ConfigMap för ProxySQL
I likhet med föregående blogginlägg kommer vi att använda ConfigMap-metoden för att koppla bort konfigurationsfilen från behållaren och även i skalbarhetssyfte. Observera att i den här installationen anser vi att vår ProxySQL-konfiguration är oföränderlig.
Skapa först ProxySQL-konfigurationsfilen, proxysql.cnf och lägg till följande rader:
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
}
)Var uppmärksam på admin_variables.admin_credentials variabel där vi använde icke-standardanvändare som är "proxysql-admin". ProxySQL reserverar standardanvändaren för "admin" endast för lokal anslutning via lokal värd. Därför måste vi använda andra användare för att komma åt ProxySQL-instansen på distans. Annars skulle du få följande felmeddelande:
ERROR 1040 (42000): User 'admin' can only connect locallyVår ProxySQL-konfiguration är baserad på våra två databasservrar som körs i MySQL-replikering som sammanfattas i följande Topology-skärmdump från ClusterControl:
Alla skrivningar ska gå till masternoden medan läsningar vidarebefordras till värdgrupp 20, som definierats under avsnittet "mysql_query_rules". Det är grunden för läs/skrivdelning och vi vill använda dem helt och hållet.
Importera sedan konfigurationsfilen till ConfigMap:
$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf
configmap/proxysql-configmap createdKontrollera om ConfigMap är inläst i Kubernetes:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 45sWordpress Pod och Service Definition
Klistra in följande rader i en fil som heter wordpress-rs-svc.yml på värden där kubectl är konfigurerad:
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 likhet med vår ProxySQL-definition består YAML av två resurser, åtskilda av "---" avgränsare kombinerade i en fil. Den första är distributionsresursen, som kommer att distribueras som en ReplicaSet, som visas under avsnittet "spec.*":
spec:
replicas: 3
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: RollingUpdateDet här avsnittet tillhandahåller distributionsspecifikationen - 3 pods att starta som matchar etiketten "app=wordpress,tier=backend". Implementeringsstrategin är RollingUpdate, vilket innebär att Kubernetes kommer att ersätta podden genom att använda rullande uppdateringssätt, samma sak som vår ProxySQL-distribution.
Nästa del är avsnittet "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 det här avsnittet säger vi åt Kubernetes att distribuera Wordpress 4.9 med Apache webbserver och vi gav behållaren namnet "wordpress". Behållaren kommer att startas om varje gång den är nere, oavsett status. Vi vill också att Kubernetes ska skicka ett antal miljövariabler:
- WORDPRESS_DB_HOST - MySQL-databasvärden. Eftersom vi använder ProxySQL som en tjänst kommer tjänstens namn att vara värdet metadata.name som är "proxysql". ProxySQL lyssnar på port 6033 efter MySQL-lastbalanserade anslutningar medan ProxySQL-administrationskonsolen är på 6032.
- WORDPRESS_DB_USER - Ange den wordpress-databasanvändare som har skapats under avsnittet "Förbereda databasen".
- WORDPRESS_DB_PASSWORD - Lösenordet för WORDPRESS_DB_USER . Eftersom vi inte vill avslöja lösenordet i den här filen kan vi dölja det med Kubernetes Secrets. Här instruerar vi Kubernetes att läsa den hemliga resursen "mysql-pass" istället. Hemligheter måste skapas i avancerat innan podden distribueras, som förklaras längre ner.
Vi vill också publicera port 80 i podden för slutanvändaren. Wordpress-innehållet som lagras inuti /var/www/html i behållaren kommer att monteras i vår beständiga lagring som körs på NFS. Vi kommer att använda resurserna PersistentVolume och PersistentVolumeClaim för detta ändamål enligt sektionen "Förbereda persistent lagring för Wordpress".
Efter brytraden "---" definierar vi en annan resurs som heter 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 den här konfigurationen vill vi att Kubernetes skapar en tjänst som heter "wordpress", lyssnar på port 30088 på alla noder (a.k.a. NodePort) till det externa nätverket och vidarebefordrar det till port 80 på alla pods märkta med "app=wordpress,tier=frontend".
Därför måste vi, baserat på vår YAML-definition ovan, förbereda ett antal Kubernetes-resurser innan vi kan börja distribuera "wordpress"-podden och tjänsten:
- PersistentVolume och PersistentVolumeClaim - För att lagra webbinnehållet i vår Wordpress-applikation, så när podden schemaläggs om till en annan arbetarnod, kommer vi inte att förlora de senaste ändringarna.
- Hemligheter - För att dölja Wordpress-databasens användarlösenord i YAML-filen.
Förbereder beständig lagring för Wordpress
En bra beständig lagring för Kubernetes bör vara tillgänglig för alla Kubernetes-noder i klustret. För det här blogginläggets skull använde vi NFS som leverantör av PersistentVolume (PV) eftersom det är enkelt och stöds direkt. NFS-servern finns någonstans utanför vårt Kubernetes-nätverk (som visas i det första arkitekturdiagrammet) och vi har konfigurerat den för att tillåta alla Kubernetes-noder med följande rad inuti /etc/exports:
/nfs 192.168.55.*(rw,sync,no_root_squash,no_all_squash)Observera att NFS-klientpaketet måste installeras på alla Kubernetes-noder. Annars skulle Kubernetes inte kunna montera NFS korrekt. På alla noder:
$ sudo apt-install nfs-common #Ubuntu/Debian
$ yum install nfs-utils #RHEL/CentOSSe också till att målkatalogen finns på NFS-servern:
(nfs-server)$ mkdir /nfs/kubernetes/wordpressSkapa sedan en fil som heter wordpress-pv-pvc.yml och lägg till följande rader:
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 definitionen ovan säger vi till Kubernetes att allokera 3 GB volymutrymme på NFS-servern för vår Wordpress-behållare. Notera för produktionsanvändning, NFS bör konfigureras med automatisk provisionerare och lagringsklass.
Skapa PV- och PVC-resurserna:
$ kubectl create -f wordpress-pv-pvc.ymlVerifiera om dessa resurser har skapats och statusen måste vara "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 22hFörbereder hemligheter för Wordpress
Skapa en hemlighet som ska användas av Wordpress-behållaren för WORDPRESS_DB_PASSWORD miljöfaktor. Anledningen är helt enkelt för att vi inte vill exponera lösenordet i klartext i YAML-filen.
Skapa en hemlig resurs som heter mysql-pass och skicka lösenordet därefter:
$ kubectl create secret generic mysql-pass --from-literal=password=passw0rdVerifiera att vår hemlighet har skapats:
$ kubectl get secrets mysql-pass
NAME TYPE DATA AGE
mysql-pass Opaque 1 7h12mDistribuera ProxySQL och Wordpress
Äntligen kan vi börja utplaceringen. Installera ProxySQL först, följt av Wordpress:
$ kubectl create -f proxysql-rs-svc.yml
$ kubectl create -f wordpress-rs-svc.ymlVi kan sedan lista ut alla poddar och tjänster som har skapats under "frontend"-nivå:
$ 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>Ovanstående utdata verifierar vår implementeringsarkitektur där vi för närvarande har tre Wordpress-poddar, exponerade på port 30088 offentligt samt vår ProxySQL-instans som är exponerad på port 30033 och 30032 externt plus 6033 och 6032 internt.
Vid det här laget ser vår arkitektur ut ungefär så här:
Port 80 publicerad av Wordpress-podarna är nu mappad till omvärlden via port 30088. Vi kan komma åt vårt blogginlägg på http://{any_kubernetes_host}:30088/ och bör omdirigeras till Wordpress-installationssidan. Om vi fortsätter med installationen skulle den hoppa över databasanslutningsdelen och direkt visa denna sida:
Det indikerar att vår MySQL- och ProxySQL-konfiguration är korrekt konfigurerad i filen wp-config.php. Annars skulle du omdirigeras till databaskonfigurationssidan.
Vår implementering är nu klar.
ProxySQL Pods och Service Management
Failover och återställning förväntas hanteras automatiskt av Kubernetes. Till exempel, om en Kubernetes-arbetare går ner, kommer podden att återskapas i nästa tillgängliga nod efter --pod-eviction-timeout (standard är 5 minuter). Om behållaren kraschar eller dödas kommer Kubernetes att ersätta den nästan omedelbart.
Vissa vanliga hanteringsuppgifter förväntas vara annorlunda när de körs inom Kubernetes, som visas i nästa avsnitt.
Ansluter till ProxySQL
Medan ProxySQL exponeras externt på port 30033 (MySQL) och 30032 (Admin), är den också tillgänglig internt via de publicerade portarna, 6033 respektive 6032. För att komma åt ProxySQL-instanserna inom Kubernetes-nätverket, använd därför CLUSTER-IP eller tjänstens namn "proxysql" som värdvärde. Till exempel, i Wordpress-podden kan du komma åt ProxySQL-administratörskonsolen genom att använda följande kommando:
$ mysql -uproxysql-admin -p -hproxysql -P6032Om du vill ansluta externt, använd porten som definieras under nodePort-värde och tjänsten YAML och välj någon av Kubernetes-noderna som värdvärde:
$ mysql -uproxysql-admin -p -hkube3.local -P30032Detsamma gäller för MySQL-lastbalanserad anslutning på port 30033 (extern) och 6033 (intern).
Skala upp och ned
Det är enkelt att skala upp med Kubernetes:
$ kubectl scale deployment proxysql --replicas=5
deployment.extensions/proxysql scaledVerifiera lanseringsstatusen:
$ kubectl rollout status deployment proxysql
deployment "proxysql" successfully rolled outNedskalning är också liknande. Här vill vi gå tillbaka från 5 till 2 repliker:
$ kubectl scale deployment proxysql --replicas=2
deployment.extensions/proxysql scaledVi kan också titta på distributionshändelserna för ProxySQL för att få en bättre bild av vad som har hänt för denna distribution genom att använda alternativet "beskriv":
$ 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 2Anslutningarna till poddarna kommer att lastbalanseras automatiskt av Kubernetes.
Konfigurationsändringar
Ett sätt att göra konfigurationsändringar på våra ProxySQL-pods är genom att versionera vår konfiguration med ett annat ConfigMap-namn. För det första, ändra vår konfigurationsfil direkt via din favorittextredigerare:
$ vim /root/proxysql.cnfLadda sedan upp den i Kubernetes ConfigMap med ett annat namn. I det här exemplet lägger vi till "-v2" i resursnamnet:
$ kubectl create configmap proxysql-configmap-v2 --from-file=proxysql.cnfKontrollera om ConfigMap är korrekt laddad:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 3d15h
proxysql-configmap-v2 1 19mÖppna ProxySQL-distributionsfilen, proxysql-rs-svc.yml och ändra följande rad under configMap-sektionen till den nya versionen:
volumes:
- name: proxysql-config
configMap:
name: proxysql-configmap-v2 #change this lineTillämpa sedan ändringarna på vår ProxySQL-distribution:
$ kubectl apply -f proxysql-rs-svc.yml
deployment.apps/proxysql configured
service/proxysql configuredVerifiera lanseringen genom att titta på ReplicaSet-händelsen med "describe"-flaggan:
$ 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 0Var uppmärksam på avsnittet "Volymer" med det nya ConfigMap-namnet. Du kan också se distributionshändelserna längst ned i utgången. Vid det här laget har vår nya konfiguration laddats in i alla ProxySQL-poddar, där Kubernetes skalat ner ProxySQL ReplicaSet till 0 (lydiga RollingUpdate-strategin) och föra dem tillbaka till det önskade tillståndet av 2 repliker.
Sluta tankar
Fram till denna punkt har vi täckt möjliga distributionssätt för ProxySQL i Kubernetes. Att köra ProxySQL med hjälp av Kubernetes ConfigMap öppnar en ny möjlighet för ProxySQL-klustring, där det är något annorlunda jämfört med det inbyggda klustringsstödet inbyggt i ProxySQL.
I det kommande blogginlägget kommer vi att utforska ProxySQL Clustering med Kubernetes ConfigMap och hur man gör det på rätt sätt. Håll utkik!