Bij het uitvoeren van gedistribueerde databaseclusters is het vrij gebruikelijk om ze te voorzien van load balancers. De voordelen zijn duidelijk:taakverdeling, verbindingsfailover en ontkoppeling van de applicatielaag van de onderliggende databasetopologieën. Voor een intelligentere taakverdeling zou een databasebewuste proxy zoals ProxySQL of MaxScale de juiste keuze zijn. In onze vorige blog hebben we je laten zien hoe je ProxySQL kunt draaien als een helpercontainer in Kubernetes. In deze blogpost laten we u zien hoe u ProxySQL kunt inzetten als Kubernetes-service. We gebruiken Wordpress als een voorbeeldtoepassing en de database-backend wordt uitgevoerd op een MySQL-replicatie met twee knooppunten die wordt geïmplementeerd met ClusterControl. Het volgende diagram illustreert onze infrastructuur:
Aangezien we een vergelijkbare opzet gaan gebruiken als in deze vorige blogpost, moet u rekening houden met duplicatie in sommige delen van de blogpost om de post leesbaarder te houden.
ProxySQL op Kubernetes
Laten we beginnen met een korte samenvatting. Het ontwerpen van een ProxySQL-architectuur is een subjectief onderwerp en sterk afhankelijk van de plaatsing van de applicatie, databasecontainers en de rol van ProxySQL zelf. Idealiter kunnen we ProxySQL configureren om door Kubernetes te worden beheerd met twee configuraties:
- ProxySQL als Kubernetes-service (gecentraliseerde implementatie)
- ProxySQL als hulpcontainer in een pod (gedistribueerde implementatie)
Beide implementaties kunnen eenvoudig worden onderscheiden door naar het volgende diagram te kijken:
Deze blogpost behandelt de eerste configuratie:ProxySQL draaien als een Kubernetes-service. De tweede configuratie is hier al behandeld. In tegenstelling tot de helper-containerbenadering, zorgt het draaien als een service ervoor dat ProxySQL-pods onafhankelijk van de applicaties leven en gemakkelijk kunnen worden geschaald en geclusterd met behulp van Kubernetes ConfigMap. Dit is absoluut een andere clusteringbenadering dan ProxySQL-native clusteringondersteuning, die afhankelijk is van configuratiecontrolesommen over ProxySQL-instanties (ook wel proxysql_servers genoemd). Bekijk deze blogpost als je meer wilt weten over ProxySQL-clustering, eenvoudig gemaakt met ClusterControl.
In Kubernetes maakt het meerlaagse configuratiesysteem van ProxySQL podclustering mogelijk met ConfigMap. Er zijn echter een aantal tekortkomingen en oplossingen om het soepel te laten werken zoals de native clustering-functie van ProxySQL doet. Op dit moment is het signaleren van een pod bij de ConfigMap-update een functie in de maak. We zullen dit onderwerp veel gedetailleerder behandelen in een volgende blogpost.
Kortom, we moeten ProxySQL-pods maken en een Kubernetes-service koppelen die toegankelijk is voor de andere pods binnen het Kubernetes-netwerk of extern. Toepassingen maken vervolgens verbinding met de ProxySQL-service via TCP/IP-netwerken op de geconfigureerde poorten. Standaard ingesteld op 6033 voor MySQL-taakverdelingsverbindingen en 6032 voor ProxySQL-beheerconsole. Als er meer dan één replica is, worden de verbindingen met de pod automatisch gebalanceerd door de Kubernetes kube-proxy-component die op elk Kubernetes-knooppunt wordt uitgevoerd.
ProxySQL als Kubernetes-service
In deze opstelling gebruiken we zowel ProxySQL als Wordpress als pods en services. Het volgende diagram illustreert onze architectuur op hoog niveau:
In deze opstelling zullen we twee pods en services implementeren:"wordpress" en "proxysql". We zullen de implementatie- en serviceverklaring samenvoegen in één YAML-bestand per applicatie en deze als één eenheid beheren. Om de inhoud van de applicatiecontainers persistent te houden over meerdere knooppunten, moeten we een geclusterd of extern bestandssysteem gebruiken, in dit geval NFS.
Het implementeren van ProxySQL als een service brengt een aantal goede dingen met zich mee ten opzichte van de helper-containerbenadering:
- Met de Kubernetes ConfigMap-aanpak kan ProxySQL worden geclusterd met een onveranderlijke configuratie.
- Kubernetes handelt ProxySQL-herstel af en balanceert de verbindingen met de instanties automatisch.
- Enkel eindpunt met implementatie van Kubernetes Virtual IP-adres genaamd ClusterIP.
- Gecentraliseerde reverse proxy-laag met gedeelde niets-architectuur.
- Kan worden gebruikt met externe applicaties buiten Kubernetes.
We zullen de implementatie starten als twee replica's voor ProxySQL en drie voor Wordpress om te demonstreren hoe u op schaal draait en de mogelijkheden voor taakverdeling die Kubernetes biedt.
De database voorbereiden
Maak de wordpress-database en gebruiker op de master en wijs deze toe met de juiste rechten:
mysql-master> CREATE DATABASE wordpress;
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql-master> GRANT ALL PRIVILEGES ON wordpress.* TO [email protected]'%';Maak ook de ProxySQL-monitoringgebruiker aan:
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'proxysqlpassw0rd';Laad vervolgens de subsidietabel opnieuw:
mysql-master> FLUSH PRIVILEGES;ProxySQL-pod en servicedefinitie
De volgende is om onze ProxySQL-implementatie voor te bereiden. Maak een bestand met de naam proxysql-rs-svc.yml en voeg de volgende regels toe:
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: frontendLaten we eens kijken waar die definities over gaan. De YAML bestaat uit twee bronnen gecombineerd in een bestand, gescheiden door een "---" scheidingsteken. De eerste bron is de implementatie, waarvoor we de volgende specificatie definiëren:
spec:
replicas: 2
selector:
matchLabels:
app: proxysql
tier: frontend
strategy:
type: RollingUpdateHet bovenstaande betekent dat we twee ProxySQL-pods willen implementeren als een ReplicaSet die overeenkomt met containers met het label "app=proxysql,tier=frontend". De implementatiestrategie specificeert de strategie die wordt gebruikt om oude pods te vervangen door nieuwe. In deze implementatie hebben we RollingUpdate gekozen, wat betekent dat de pods worden bijgewerkt op een doorlopende update-manier, één pod per keer.
Het volgende deel is de sjabloon van de container:
- 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-configmapIn de spec.templates.spec.containers.* sectie, vertellen we Kubernetes om ProxySQL te implementeren met behulp van severalnines/proxysql afbeeldingsversie 1.4.12. We willen ook dat Kubernetes ons aangepaste, vooraf geconfigureerde configuratiebestand koppelt en toewijst aan /etc/proxysql.cnf in de container. De actieve pods zullen twee poorten publiceren - 6033 en 6032. We definiëren ook de sectie "volumes", waar we Kubernetes instrueren om de ConfigMap te koppelen als een volume in de ProxySQL-pods die door volumeMounts moeten worden gemount.
De tweede bron is de service. Een Kubernetes-service is een abstractielaag die de logische set pods definieert en een beleid voor toegang tot deze. In deze sectie definiëren we het volgende:
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: frontendIn dit geval willen we dat onze ProxySQL toegankelijk is vanaf het externe netwerk, dus het type NodePort is het gekozen type. Hiermee wordt de nodePort op alle Kubernetes-knooppunten in het cluster gepubliceerd. Het bereik van geldige poorten voor NodePort-bronnen is 30000-32767. We kozen poort 30033 voor MySQL-load-balanced verbindingen die is toegewezen aan poort 6033 van de ProxySQL-pods en poort 30032 voor ProxySQL-beheerpoort toegewezen aan 6032.
Daarom moeten we, op basis van onze YAML-definitie hierboven, de volgende Kubernetes-bron voorbereiden voordat we kunnen beginnen met het implementeren van de "proxysql"-pod:
- ConfigMap - Om het ProxySQL-configuratiebestand als een volume op te slaan, zodat het aan meerdere pods kan worden gekoppeld en opnieuw kan worden aangekoppeld als de pod opnieuw wordt gepland naar het andere Kubernetes-knooppunt.
ConfigMap voorbereiden voor ProxySQL
Net als bij de vorige blogpost, gaan we de ConfigMap-aanpak gebruiken om het configuratiebestand los te koppelen van de container en ook voor schaalbaarheid. Houd er rekening mee dat we in deze opstelling van mening zijn dat onze ProxySQL-configuratie onveranderlijk is.
Maak eerst het ProxySQL-configuratiebestand, proxysql.cnf en voeg de volgende regels toe:
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
}
)Let op de admin_variables.admin_credentials variabele waarbij we een niet-standaard gebruiker hebben gebruikt, namelijk "proxysql-admin". ProxySQL reserveert de standaard "admin"-gebruiker alleen voor lokale verbinding via localhost. Daarom moeten we andere gebruikers gebruiken om op afstand toegang te krijgen tot de ProxySQL-instantie. Anders krijgt u de volgende foutmelding:
ERROR 1040 (42000): User 'admin' can only connect locallyOnze ProxySQL-configuratie is gebaseerd op onze twee databaseservers die worden uitgevoerd in MySQL-replicatie, zoals samengevat in het volgende screenshot van de topologie, genomen uit ClusterControl:
Alle schrijfbewerkingen moeten naar het hoofdknooppunt gaan, terwijl de leesbewerkingen worden doorgestuurd naar hostgroep 20, zoals gedefinieerd in de sectie "mysql_query_rules". Dat is de basis van het splitsen van lezen/schrijven en we willen ze helemaal gebruiken.
Importeer vervolgens het configuratiebestand in ConfigMap:
$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf
configmap/proxysql-configmap createdControleer of de ConfigMap in Kubernetes is geladen:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 45sWordpress-pod en servicedefinitie
Plak nu de volgende regels in een bestand met de naam wordpress-rs-svc.yml op de host waar kubectl is geconfigureerd:
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: frontendNet als onze ProxySQL-definitie, bestaat de YAML uit twee bronnen, gescheiden door een "---" scheidingsteken gecombineerd in een bestand. De eerste is de implementatiebron, die zal worden geïmplementeerd als een ReplicaSet, zoals weergegeven in de sectie "spec.*":
spec:
replicas: 3
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: RollingUpdateDeze sectie bevat de implementatiespecificatie - 3 pods om te starten die overeenkomen met het label "app=wordpress,tier=backend". De implementatiestrategie is RollingUpdate, wat betekent dat Kubernetes de pod vervangt door gebruik te maken van rolling update-mode, hetzelfde met onze ProxySQL-implementatie.
Het volgende deel is de sectie "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
In deze sectie vertellen we Kubernetes om Wordpress 4.9 te implementeren met behulp van de Apache-webserver en we gaven de container de naam "wordpress". De container wordt elke keer dat deze offline is opnieuw gestart, ongeacht de status. We willen ook dat Kubernetes een aantal omgevingsvariabelen doorgeeft:
- WORDPRESS_DB_HOST - De MySQL-databasehost. Aangezien we ProxySQL als service gebruiken, is de servicenaam de waarde van metadata.name wat "proxysql" is. ProxySQL luistert op poort 6033 voor MySQL load-balanced verbindingen terwijl de ProxySQL-beheerconsole op 6032 staat.
- WORDPRESS_DB_USER - Geef de gebruiker van de wordpress-database op die is aangemaakt in het gedeelte "De database voorbereiden".
- WORDPRESS_DB_PASSWORD - Het wachtwoord voor WORDPRESS_DB_USER . Omdat we het wachtwoord in dit bestand niet willen onthullen, kunnen we het verbergen met Kubernetes Secrets. Hier instrueren we Kubernetes om in plaats daarvan de geheime bron "mysql-pass" te lezen. Geheimen moeten vooraf worden aangemaakt voordat de pod wordt geïmplementeerd, zoals verderop wordt uitgelegd.
We willen ook poort 80 van de pod publiceren voor de eindgebruiker. De Wordpress-inhoud die in /var/www/html in de container is opgeslagen, wordt gemount in onze permanente opslag die op NFS draait. We zullen hiervoor de bronnen PersistentVolume en PersistentVolumeClaim gebruiken, zoals weergegeven in het gedeelte 'Persistente opslag voor Wordpress voorbereiden'.
Na de onderbrekingsregel "---" definiëren we een andere bron met de naam 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: frontendIn deze configuratie willen we dat Kubernetes een service maakt met de naam "wordpress", luistert op poort 30088 op alle knooppunten (ook bekend als NodePort) naar het externe netwerk en deze doorstuurt naar poort 80 op alle pods met het label "app=wordpress,tier=frontend".
Daarom moeten we, op basis van onze YAML-definitie hierboven, een aantal Kubernetes-bronnen voorbereiden voordat we kunnen beginnen met het implementeren van de "wordpress"-pod en -service:
- PersistentVolume en PersistentVolumeClaim - Om de webinhoud van onze Wordpress-toepassing op te slaan, zodat we de laatste wijzigingen niet verliezen wanneer de pod wordt verplaatst naar een ander werkknooppunt.
- Geheimen - Om het gebruikerswachtwoord van de Wordpress-database in het YAML-bestand te verbergen.
Persistente opslag voorbereiden voor Wordpress
Een goede permanente opslag voor Kubernetes moet toegankelijk zijn voor alle Kubernetes-knooppunten in het cluster. Omwille van deze blogpost hebben we NFS gebruikt als de PersistentVolume (PV)-provider omdat het eenvoudig is en out-of-the-box wordt ondersteund. De NFS-server bevindt zich ergens buiten ons Kubernetes-netwerk (zoals weergegeven in het eerste architectuurdiagram) en we hebben deze geconfigureerd om alle Kubernetes-knooppunten toe te staan met de volgende regel in /etc/exports:
/nfs 192.168.55.*(rw,sync,no_root_squash,no_all_squash)Houd er rekening mee dat het NFS-clientpakket op alle Kubernetes-knooppunten moet zijn geïnstalleerd. Anders zou Kubernetes de NFS niet correct kunnen mounten. Op alle knooppunten:
$ sudo apt-install nfs-common #Ubuntu/Debian
$ yum install nfs-utils #RHEL/CentOSZorg er ook voor dat op de NFS-server de doelmap bestaat:
(nfs-server)$ mkdir /nfs/kubernetes/wordpressMaak vervolgens een bestand met de naam wordpress-pv-pvc.yml en voeg de volgende regels toe:
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: frontendIn de bovenstaande definitie vertellen we Kubernetes om 3 GB volumeruimte op de NFS-server toe te wijzen voor onze Wordpress-container. Let op voor productiegebruik, NFS moet worden geconfigureerd met automatische voorziening en opslagklasse.
Maak de PV- en PVC-bronnen:
$ kubectl create -f wordpress-pv-pvc.ymlControleer of deze bronnen zijn gemaakt en of de status "Gebonden" moet zijn:
$ 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 22hGeheimen voorbereiden voor Wordpress
Maak een geheim dat door de Wordpress-container moet worden gebruikt voor WORDPRESS_DB_PASSWORD omgevingsvariabele. De reden is simpelweg omdat we het wachtwoord niet in leesbare tekst in het YAML-bestand willen weergeven.
Maak een geheime bron met de naam mysql-pass en geef het wachtwoord dienovereenkomstig door:
$ kubectl create secret generic mysql-pass --from-literal=password=passw0rdControleer of ons geheim is aangemaakt:
$ kubectl get secrets mysql-pass
NAME TYPE DATA AGE
mysql-pass Opaque 1 7h12mProxySQL en Wordpress implementeren
Eindelijk kunnen we beginnen met de implementatie. Implementeer eerst ProxySQL, gevolgd door Wordpress:
$ kubectl create -f proxysql-rs-svc.yml
$ kubectl create -f wordpress-rs-svc.ymlWe kunnen dan alle pods en services weergeven die zijn gemaakt onder de "frontend"-laag:
$ 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>De bovenstaande uitvoer verifieert onze implementatie-architectuur waar we momenteel drie Wordpress-pods hebben, openbaar beschikbaar op poort 30088, evenals onze ProxySQL-instantie die extern wordt weergegeven op poort 30033 en 30032 plus intern 6033 en 6032.
Op dit moment ziet onze architectuur er ongeveer zo uit:
Poort 80, gepubliceerd door de Wordpress-pods, is nu toegewezen aan de buitenwereld via poort 30088. We hebben toegang tot onze blogpost op http://{any_kubernetes_host}:30088/ en moeten worden doorgestuurd naar de installatiepagina van Wordpress. Als we doorgaan met de installatie, wordt het gedeelte over de databaseverbinding overgeslagen en wordt deze pagina direct weergegeven:
Het geeft aan dat onze MySQL- en ProxySQL-configuratie correct is geconfigureerd in het wp-config.php-bestand. Anders wordt u doorgestuurd naar de databaseconfiguratiepagina.
Onze implementatie is nu voltooid.
ProxySQL-pods en servicebeheer
Failover en herstel worden naar verwachting automatisch afgehandeld door Kubernetes. Als een Kubernetes-worker bijvoorbeeld uitvalt, wordt de pod opnieuw gemaakt in het volgende beschikbare knooppunt na --pod-eviction-timeout (standaard 5 minuten). Als de container crasht of doodgaat, zal Kubernetes hem vrijwel onmiddellijk vervangen.
Sommige algemene beheertaken zullen naar verwachting anders zijn wanneer ze binnen Kubernetes worden uitgevoerd, zoals weergegeven in de volgende secties.
Verbinding maken met ProxySQL
Hoewel ProxySQL extern wordt weergegeven op poort 30033 (MySQL) en 30032 (Admin), is het ook intern toegankelijk via de gepubliceerde poorten, respectievelijk 6033 en 6032. Om toegang te krijgen tot de ProxySQL-instanties binnen het Kubernetes-netwerk, gebruikt u dus de CLUSTER-IP of de servicenaam "proxysql" als hostwaarde. In de Wordpress-pod kunt u bijvoorbeeld toegang krijgen tot de ProxySQL-beheerconsole door de volgende opdracht te gebruiken:
$ mysql -uproxysql-admin -p -hproxysql -P6032Als u extern verbinding wilt maken, gebruikt u de poort die is gedefinieerd onder nodePort value he service YAML en kiest u een van de Kubernetes-knooppunten als hostwaarde:
$ mysql -uproxysql-admin -p -hkube3.local -P30032Hetzelfde geldt voor de MySQL load-balanced verbinding op poort 30033 (extern) en 6033 (intern).
Op en neer schalen
Opschalen is eenvoudig met Kubernetes:
$ kubectl scale deployment proxysql --replicas=5
deployment.extensions/proxysql scaledControleer de uitrolstatus:
$ kubectl rollout status deployment proxysql
deployment "proxysql" successfully rolled outVerkleinen is ook vergelijkbaar. Hier willen we teruggaan van 5 naar 2 replica's:
$ kubectl scale deployment proxysql --replicas=2
deployment.extensions/proxysql scaledWe kunnen ook kijken naar de implementatiegebeurtenissen voor ProxySQL om een beter beeld te krijgen van wat er voor deze implementatie is gebeurd door de optie "beschrijven" te gebruiken:
$ 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 2De verbindingen met de pods worden automatisch door Kubernetes in balans gebracht.
Configuratiewijzigingen
Een manier om configuratiewijzigingen aan te brengen op onze ProxySQL-pods is door onze configuratie te versiebeheer met een andere ConfigMap-naam. Wijzig eerst ons configuratiebestand rechtstreeks via uw favoriete teksteditor:
$ vim /root/proxysql.cnfLaad het vervolgens met een andere naam in Kubernetes ConfigMap. In dit voorbeeld voegen we "-v2" toe aan de resourcenaam:
$ kubectl create configmap proxysql-configmap-v2 --from-file=proxysql.cnfControleer of de ConfigMap correct is geladen:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 3d15h
proxysql-configmap-v2 1 19mOpen het ProxySQL-implementatiebestand, proxysql-rs-svc.yml en verander de volgende regel onder de sectie configMap naar de nieuwe versie:
volumes:
- name: proxysql-config
configMap:
name: proxysql-configmap-v2 #change this linePas vervolgens de wijzigingen toe op onze ProxySQL-implementatie:
$ kubectl apply -f proxysql-rs-svc.yml
deployment.apps/proxysql configured
service/proxysql configuredControleer de uitrol door naar de ReplicaSet-gebeurtenis te kijken met behulp van de "describe"-vlag:
$ 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 0Let op de sectie "Volumes" met de nieuwe ConfigMap-naam. U kunt de implementatiegebeurtenissen ook onder aan de uitvoer zien. Op dit moment is onze nieuwe configuratie in alle ProxySQL-pods geladen, waar Kubernetes de ProxySQL ReplicaSet naar 0 heeft geschaald (volgens de RollingUpdate-strategie) en ze terugbrengt naar de gewenste status van 2 replica's.
Laatste gedachten
Tot nu toe hebben we de mogelijke implementatiebenadering voor ProxySQL in Kubernetes behandeld. Het uitvoeren van ProxySQL met behulp van Kubernetes ConfigMap opent een nieuwe mogelijkheid voor ProxySQL-clustering, waar het enigszins verschilt van de native clusteringondersteuning die in ProxySQL is ingebouwd.
In de komende blogpost zullen we ProxySQL-clustering onderzoeken met Kubernetes ConfigMap en hoe we dit op de juiste manier kunnen doen. Blijf op de hoogte!