Ao executar clusters de banco de dados distribuídos, é bastante comum enfrentá-los com balanceadores de carga. As vantagens são claras - balanceamento de carga, failover de conexão e desacoplamento da camada de aplicativo das topologias de banco de dados subjacentes. Para um balanceamento de carga mais inteligente, um proxy com reconhecimento de banco de dados como ProxySQL ou MaxScale seria o caminho a seguir. Em nosso blog anterior, mostramos como executar o ProxySQL como um contêiner auxiliar no Kubernetes. Nesta postagem do blog, mostraremos como implantar o ProxySQL como um serviço do Kubernetes. Usaremos o Wordpress como um aplicativo de exemplo e o back-end do banco de dados está sendo executado em uma replicação MySQL de dois nós implantada usando o ClusterControl. O diagrama a seguir ilustra nossa infraestrutura:
Como vamos implantar uma configuração semelhante à desta postagem de blog anterior, espere duplicação em algumas partes da postagem de blog para manter a postagem mais legível.
ProxySQL no Kubernetes
Vamos começar com um pouco de recapitulação. Projetar uma arquitetura ProxySQL é um tópico subjetivo e altamente dependente do posicionamento do aplicativo, dos contêineres do banco de dados, bem como da função do próprio ProxySQL. Idealmente, podemos configurar o ProxySQL para ser gerenciado pelo Kubernetes com duas configurações:
- ProxySQL como um serviço Kubernetes (implantação centralizada)
- ProxySQL como um contêiner auxiliar em um pod (implantação distribuída)
Ambas as implantações podem ser distinguidas facilmente observando o diagrama a seguir:
Esta postagem de blog abordará a primeira configuração - executando o ProxySQL como um serviço do Kubernetes. A segunda configuração já está coberta aqui. Em contraste com a abordagem de contêiner auxiliar, a execução como um serviço faz com que os pods do ProxySQL vivam independentemente dos aplicativos e possam ser facilmente dimensionados e agrupados em cluster com a ajuda do Kubernetes ConfigMap. Essa é definitivamente uma abordagem de cluster diferente do suporte de cluster nativo do ProxySQL, que depende da soma de verificação de configuração nas instâncias do ProxySQL (também conhecido como proxysql_servers). Confira esta postagem de blog se quiser saber mais sobre o clustering ProxySQL facilitado com o ClusterControl.
No Kubernetes, o sistema de configuração multicamada do ProxySQL possibilita o agrupamento de pods com o ConfigMap. No entanto, existem várias deficiências e soluções alternativas para fazê-lo funcionar sem problemas, como o recurso de cluster nativo do ProxySQL faz. No momento, sinalizar um pod na atualização do ConfigMap é um recurso em andamento. Abordaremos esse tópico com muito mais detalhes em uma próxima postagem do blog.
Basicamente, precisamos criar pods ProxySQL e anexar um serviço Kubernetes para ser acessado pelos outros pods dentro da rede Kubernetes ou externamente. Os aplicativos se conectarão ao serviço ProxySQL via rede TCP/IP nas portas configuradas. O padrão é 6033 para conexões com balanceamento de carga do MySQL e 6032 para console de administração do ProxySQL. Com mais de uma réplica, as conexões com o pod serão balanceadas de carga automaticamente pelo componente kube-proxy do Kubernetes em execução em cada nó do Kubernetes.
ProxySQL como serviço Kubernetes
Nesta configuração, executamos o ProxySQL e o Wordpress como pods e serviços. O diagrama a seguir ilustra nossa arquitetura de alto nível:
Nesta configuração, implantaremos dois pods e serviços - "wordpress" e "proxysql". Combinaremos a declaração de implantação e serviço em um arquivo YAML por aplicativo e os gerenciaremos como uma unidade. Para manter o conteúdo dos contêineres do aplicativo persistente em vários nós, temos que usar um sistema de arquivos em cluster ou remoto, que neste caso é o NFS.
A implantação do ProxySQL como um serviço traz algumas coisas boas sobre a abordagem do contêiner auxiliar:
- Usando a abordagem ConfigMap do Kubernetes, o ProxySQL pode ser agrupado com configuração imutável.
- O Kubernetes lida com a recuperação do ProxySQL e equilibra as conexões com as instâncias automaticamente.
- Um único endpoint com implementação de endereço IP virtual do Kubernetes chamado ClusterIP.
- Nível de proxy reverso centralizado com arquitetura sem compartilhamento.
- Pode ser usado com aplicativos externos fora do Kubernetes.
Iniciaremos a implantação como duas réplicas para ProxySQL e três para Wordpress para demonstrar a execução em escala e os recursos de balanceamento de carga que o Kubernetes oferece.
Preparando o banco de dados
Crie o banco de dados wordpress e o usuário no mestre e atribua com o privilégio correto:
mysql-master> CREATE DATABASE wordpress;
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'passw0rd';
mysql-master> GRANT ALL PRIVILEGES ON wordpress.* TO [email protected]'%';Além disso, crie o usuário de monitoramento ProxySQL:
mysql-master> CREATE USER [email protected]'%' IDENTIFIED BY 'proxysqlpassw0rd';Em seguida, recarregue a tabela de concessões:
mysql-master> FLUSH PRIVILEGES;Pod ProxySQL e definição de serviço
O próximo é preparar nossa implantação do ProxySQL. Crie um arquivo chamado proxysql-rs-svc.yml e adicione as seguintes linhas:
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: frontendVamos ver do que se tratam essas definições. O YAML consiste em dois recursos combinados em um arquivo, separados pelo delimitador "---". O primeiro recurso é o Deployment, onde definimos a seguinte especificação:
spec:
replicas: 2
selector:
matchLabels:
app: proxysql
tier: frontend
strategy:
type: RollingUpdateO acima significa que gostaríamos de implantar dois pods ProxySQL como um ReplicaSet que corresponda a contêineres rotulados com "app=proxysql,tier=frontend". A estratégia de implantação especifica a estratégia usada para substituir pods antigos por novos. Nesta implantação, escolhemos RollingUpdate, o que significa que os pods serão atualizados de forma contínua, um pod por vez.
A próxima parte é o template do 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-configmapEm spec.templates.spec.containers.* seção, estamos dizendo ao Kubernetes para implantar o ProxySQL usando severalnines/proxysql versão da imagem 1.4.12. Também queremos que o Kubernetes monte nosso arquivo de configuração personalizado e pré-configurado e o mapeie para /etc/proxysql.cnf dentro do contêiner. Os pods em execução publicarão duas portas - 6033 e 6032. Também definimos a seção "volumes", onde instruímos o Kubernetes a montar o ConfigMap como um volume dentro dos pods ProxySQL a serem montados por volumeMounts.
O segundo recurso é o serviço. Um serviço Kubernetes é uma camada de abstração que define o conjunto lógico de pods e uma política para acessá-los. Nesta seção, definimos o seguinte:
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: frontendNeste caso, queremos que nosso ProxySQL seja acessado a partir da rede externa, portanto, o tipo NodePort é o tipo escolhido. Isso publicará o nodePort em todos os nós do Kubernetes no cluster. O intervalo de portas válidas para o recurso NodePort é 30000-32767. Escolhemos a porta 30033 para conexões balanceadas de carga do MySQL, que é mapeada para a porta 6033 dos pods do ProxySQL e a porta 30032 para a porta de administração do ProxySQL mapeada para 6032.
Portanto, com base em nossa definição de YAML acima, precisamos preparar o seguinte recurso do Kubernetes antes de começar a implantar o pod "proxysql":
- ConfigMap - Para armazenar o arquivo de configuração do ProxySQL como um volume para que possa ser montado em vários pods e remontado novamente se o pod estiver sendo reprogramado para o outro nó do Kubernetes.
Preparando o ConfigMap para ProxySQL
Semelhante à postagem anterior do blog, usaremos a abordagem ConfigMap para desacoplar o arquivo de configuração do contêiner e também para fins de escalabilidade. Observe que nesta configuração, consideramos que nossa configuração de ProxySQL é imutável.
Primeiramente, crie o arquivo de configuração do ProxySQL, proxysql.cnf e adicione as seguintes linhas:
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
}
)Preste atenção nas admin_variables.admin_credentials variável onde usamos usuário não padrão que é "proxysql-admin". O ProxySQL reserva o usuário "admin" padrão apenas para conexão local via localhost. Portanto, temos que usar outros usuários para acessar a instância ProxySQL remotamente. Caso contrário, você obteria o seguinte erro:
ERROR 1040 (42000): User 'admin' can only connect locallyNossa configuração do ProxySQL é baseada em nossos dois servidores de banco de dados em execução no MySQL Replication, conforme resumido na captura de tela da Topologia a seguir, tirada do ClusterControl:
Todas as gravações devem ir para o nó mestre enquanto as leituras são encaminhadas para o hostgroup 20, conforme definido na seção "mysql_query_rules". Esse é o básico da divisão de leitura/gravação e queremos utilizá-los completamente.
Em seguida, importe o arquivo de configuração para o ConfigMap:
$ kubectl create configmap proxysql-configmap --from-file=proxysql.cnf
configmap/proxysql-configmap createdVerifique se o ConfigMap está carregado no Kubernetes:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 45sPod do WordPress e definição de serviço
Agora, cole as seguintes linhas em um arquivo chamado wordpress-rs-svc.yml no host onde o kubectl está configurado:
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: frontendSemelhante à nossa definição de ProxySQL, o YAML consiste em dois recursos, separados pelo delimitador "---" combinado em um arquivo. O primeiro é o recurso Deployment, que será implantado como um ReplicaSet, conforme mostrado na seção "spec.*":
spec:
replicas: 3
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: RollingUpdateEsta seção fornece a especificação de implantação - 3 pods para iniciar que correspondem ao rótulo "app=wordpress,tier=backend". A estratégia de implantação é RollingUpdate, o que significa que a maneira como o Kubernetes substituirá o pod é usando o modo de atualização contínua, o mesmo com nossa implantação do ProxySQL.
A próxima parte é a seção "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/htmlNesta seção, estamos dizendo ao Kubernetes para implantar o Wordpress 4.9 usando o servidor web Apache e demos ao contêiner o nome "wordpress". O contêiner será reiniciado sempre que estiver inativo, independentemente do status. Também queremos que o Kubernetes passe várias variáveis de ambiente:
- WORDPRESS_DB_HOST - O host do banco de dados MySQL. Como estamos usando o ProxySQL como um serviço, o nome do serviço será o valor de metadata.name que é "proxysql". O ProxySQL escuta na porta 6033 para conexões com balanceamento de carga do MySQL enquanto o console de administração do ProxySQL está em 6032.
- WORDPRESS_DB_USER - Especifique o usuário do banco de dados wordpress que foi criado na seção "Preparando o banco de dados".
- WORDPRESS_DB_PASSWORD - A senha para WORDPRESS_DB_USER . Como não queremos expor a senha neste arquivo, podemos ocultá-la usando o Kubernetes Secrets. Aqui instruímos o Kubernetes a ler o recurso secreto "mysql-pass". Os segredos precisam ser criados com antecedência antes da implantação do pod, conforme explicado mais abaixo.
Também queremos publicar a porta 80 do pod para o usuário final. O conteúdo do Wordpress armazenado em /var/www/html no container será montado em nosso armazenamento persistente rodando em NFS. Usaremos os recursos PersistentVolume e PersistentVolumeClaim para essa finalidade, conforme mostrado na seção "Preparando armazenamento persistente para Wordpress".
Após a linha de quebra "---", definimos outro recurso chamado Serviço:
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: frontendNesta configuração, gostaríamos que o Kubernetes criasse um serviço chamado "wordpress", escute na porta 30088 em todos os nós (também conhecido como NodePort) para a rede externa e o encaminhe para a porta 80 em todos os pods rotulados com "app=wordpress,tier=a parte dianteira".
Portanto, com base em nossa definição de YAML acima, precisamos preparar vários recursos do Kubernetes antes de começar a implantar o pod e o serviço "wordpress":
- Volume Persistente e PersistentVolumeClaim - Para armazenar o conteúdo da web do nosso aplicativo Wordpress, para que quando o pod estiver sendo reprogramado para outro nó de trabalho, não percamos as últimas alterações.
- Segredos - Para ocultar a senha do usuário do banco de dados Wordpress dentro do arquivo YAML.
Preparando armazenamento persistente para Wordpress
Um bom armazenamento persistente para Kubernetes deve ser acessível por todos os nós Kubernetes no cluster. Para esta postagem do blog, usamos o NFS como o provedor PersistentVolume (PV) porque é fácil e com suporte pronto para uso. O servidor NFS está localizado em algum lugar fora de nossa rede Kubernetes (como mostrado no primeiro diagrama de arquitetura) e nós o configuramos para permitir todos os nós Kubernetes com a seguinte linha dentro de /etc/exports:
/nfs 192.168.55.*(rw,sync,no_root_squash,no_all_squash)Observe que o pacote do cliente NFS deve ser instalado em todos os nós do Kubernetes. Caso contrário, o Kubernetes não poderá montar o NFS corretamente. Em todos os nós:
$ sudo apt-install nfs-common #Ubuntu/Debian
$ yum install nfs-utils #RHEL/CentOSAlém disso, verifique se no servidor NFS existe o diretório de destino:
(nfs-server)$ mkdir /nfs/kubernetes/wordpressEm seguida, crie um arquivo chamado wordpress-pv-pvc.yml e adicione as seguintes linhas:
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: frontendNa definição acima, estamos dizendo ao Kubernetes para alocar 3 GB de espaço de volume no servidor NFS para nosso contêiner Wordpress. Anote o uso de produção, o NFS deve ser configurado com provisionador automático e classe de armazenamento.
Crie os recursos PV e PVC:
$ kubectl create -f wordpress-pv-pvc.ymlVerifique se esses recursos foram criados e o status deve ser "Ligado":
$ 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 22hPreparando segredos para Wordpress
Crie um segredo para ser usado pelo contêiner do Wordpress para WORDPRESS_DB_PASSWORD variável de ambiente. A razão é simplesmente porque não queremos expor a senha em texto não criptografado dentro do arquivo YAML.
Crie um recurso secreto chamado mysql-pass e passe a senha de acordo:
$ kubectl create secret generic mysql-pass --from-literal=password=passw0rdVerifique se nosso segredo foi criado:
$ kubectl get secrets mysql-pass
NAME TYPE DATA AGE
mysql-pass Opaque 1 7h12mImplantando ProxySQL e Wordpress
Finalmente, podemos iniciar a implantação. Implante o ProxySQL primeiro, seguido pelo Wordpress:
$ kubectl create -f proxysql-rs-svc.yml
$ kubectl create -f wordpress-rs-svc.ymlPodemos listar todos os pods e serviços que foram criados na camada "frontend":
$ 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>A saída acima verifica nossa arquitetura de implantação onde atualmente temos três pods do Wordpress, expostos na porta 30088 publicamente, bem como nossa instância ProxySQL que está exposta na porta 30033 e 30032 externamente mais 6033 e 6032 internamente.
Neste ponto, nossa arquitetura está mais ou menos assim:
A porta 80 publicada pelos pods do Wordpress agora está mapeada para o mundo exterior através da porta 30088. Podemos acessar nossa postagem no blog em http://{any_kubernetes_host}:30088/ e devemos ser redirecionados para a página de instalação do Wordpress. Se continuarmos com a instalação, ele pularia a parte de conexão do banco de dados e mostraria diretamente esta página:
Indica que nossa configuração MySQL e ProxySQL está configurada corretamente dentro do arquivo wp-config.php. Caso contrário, você será redirecionado para a página de configuração do banco de dados.
Nossa implantação está concluída.
Pods ProxySQL e gerenciamento de serviços
Espera-se que o failover e a recuperação sejam tratados automaticamente pelo Kubernetes. Por exemplo, se um trabalhador do Kubernetes ficar inativo, o pod será recriado no próximo nó disponível após --pod-eviction-timeout (o padrão é 5 minutos). Se o contêiner travar ou for morto, o Kubernetes o substituirá quase instantaneamente.
Espera-se que algumas tarefas comuns de gerenciamento sejam diferentes ao serem executadas no Kubernetes, conforme mostrado nas próximas seções.
Conectando ao ProxySQL
Enquanto o ProxySQL é exposto externamente na porta 30033 (MySQL) e 30032 (Admin), também é acessível internamente através das portas publicadas, 6033 e 6032, respectivamente. Assim, para acessar as instâncias do ProxySQL na rede Kubernetes, use o CLUSTER-IP ou o nome do serviço "proxysql" como valor do host. Por exemplo, no pod do Wordpress, você pode acessar o console de administração do ProxySQL usando o seguinte comando:
$ mysql -uproxysql-admin -p -hproxysql -P6032Se você quiser se conectar externamente, use a porta definida no valor nodePort no serviço YAML e escolha qualquer nó do Kubernetes como o valor do host:
$ mysql -uproxysql-admin -p -hkube3.local -P30032O mesmo se aplica à conexão com balanceamento de carga do MySQL na porta 30033 (externa) e 6033 (interna).
Escalando para cima e para baixo
A ampliação é fácil com o Kubernetes:
$ kubectl scale deployment proxysql --replicas=5
deployment.extensions/proxysql scaledVerifique o status de lançamento:
$ kubectl rollout status deployment proxysql
deployment "proxysql" successfully rolled outA redução também é semelhante. Aqui queremos reverter de 5 para 2 réplicas:
$ kubectl scale deployment proxysql --replicas=2
deployment.extensions/proxysql scaledTambém podemos observar os eventos de implantação do ProxySQL para obter uma imagem melhor do que aconteceu para essa implantação usando a opção "describe":
$ 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 2As conexões com os pods serão balanceadas automaticamente pelo Kubernetes.
Mudanças de configuração
Uma maneira de fazer alterações de configuração em nossos pods ProxySQL é fazer a versão de nossa configuração usando outro nome de ConfigMap. Em primeiro lugar, modifique nosso arquivo de configuração diretamente através do seu editor de texto favorito:
$ vim /root/proxysql.cnfEm seguida, carregue-o no Kubernetes ConfigMap com um nome diferente. Neste exemplo, anexamos "-v2" no nome do recurso:
$ kubectl create configmap proxysql-configmap-v2 --from-file=proxysql.cnfVerifique se o ConfigMap está carregado corretamente:
$ kubectl get configmap
NAME DATA AGE
proxysql-configmap 1 3d15h
proxysql-configmap-v2 1 19mAbra o arquivo de implantação do ProxySQL, proxysql-rs-svc.yml e altere a seguinte linha na seção configMap para a nova versão:
volumes:
- name: proxysql-config
configMap:
name: proxysql-configmap-v2 #change this lineEm seguida, aplique as alterações à nossa implantação do ProxySQL:
$ kubectl apply -f proxysql-rs-svc.yml
deployment.apps/proxysql configured
service/proxysql configuredVerifique o lançamento observando o evento ReplicaSet usando o sinalizador "describe":
$ 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 0Preste atenção na seção "Volumes" com o novo nome do ConfigMap. Você também pode ver os eventos de implantação na parte inferior da saída. Neste ponto, nossa nova configuração foi carregada em todos os pods do ProxySQL, onde o Kubernetes reduziu o ProxySQL ReplicaSet para 0 (obedecendo à estratégia RollingUpdate) e os trouxe de volta ao estado desejado de 2 réplicas.
Considerações finais
Até este ponto, abordamos uma possível abordagem de implantação para ProxySQL no Kubernetes. A execução do ProxySQL com a ajuda do Kubernetes ConfigMap abre uma nova possibilidade de clustering do ProxySQL, onde é um pouco diferente em comparação com o suporte de cluster nativo embutido no ProxySQL.
Na próxima postagem do blog, exploraremos o ProxySQL Clustering usando o Kubernetes ConfigMap e como fazer isso da maneira certa. Fique atento!
