Adicionamos a capacidade de iniciar convenientemente o Kubernetes no serviço Virtual Private Cloud no modo de teste beta inicial.
Essa funcionalidade será útil para usuários que precisam de gerenciamento conveniente de um grande número de aplicativos em execução como contêineres. O Kubernetes oferece ferramentas para dimensionamento, autocorreção e balanceamento de carga para contêineres executados dentro de um cluster.
Como o serviço de nuvem privada virtual é baseado no OpenStack, usamos um de seus componentes - o OpenStack Magnum . Permite criar rapidamente clusters Kubernetes privados com o número desejado de nós.
Atualmente, qualquer usuário do nosso serviço pode criar vários clusters independentes em seu projeto. Como nós de cluster, serão usadas máquinas virtuais, cuja configuração pode ser selecionada e alterada.
Neste artigo, falaremos sobre os principais objetos do cluster Kubernetes e usaremos os exemplos para analisar o processo de criação de um cluster usando o OpenStack Magnum.
Criar e gerenciar um cluster Kubernetes
Atualmente, a criação de um cluster Kubernetes é possível apenas por meio de utilitários do console ou da API OpenStack nas zonas de disponibilidade ru-1a e ru-1b (São Petersburgo).
Para começar, você precisará de:
- Crie um novo ou use um projeto VPC existente;
- Crie um usuário com uma chave SSH ;
- Adicione um usuário ao projeto criado na página de gerenciamento de projetos;
- Vá para o projeto e obtenha o arquivo de acesso na guia Acesso ;
- Instale o cliente do console openstack com a biblioteca python-magnumclient ;
- Instale o cliente do console kubectl .
Para instalar o cliente do console openstack , você pode usar as instruções no link ; no entanto, lembre-se de que, para esse cliente, você também precisará instalar a biblioteca python-magnumclient para suportar a criação de clusters Kubernetes.
O conjunto completo de comandos para instalar um cliente openstack com o plug-in necessário para sistemas operacionais da família Ubuntu / Debian:
$ sudo apt update $ sudo apt -y install curl python-pip python-dev python3-dev git libxml2-dev libxslt1-dev python-openssl python3-openssl python-pyasn1 libffi-dev libssl-dev build-essential $ sudo pip install -UI pbr setuptools pytz $ sudo pip install -UI git+https://github.com/openstack/python-openstackclient $ sudo pip install -UI git+https://github.com/openstack/python-magnumclient
O conjunto completo de comandos para instalar um cliente openstack com o plug-in necessário para sistemas operacionais da família Fedora / CentOS:
$ sudo yum -y install python-pip gcc libffi-devel python-devel libxslt-devel openssl-devel git libffi-devel $ sudo pip install -UI pbr setuptools pytz $ sudo pip install -UI git+https://github.com/openstack/python-openstackclient $ sudo pip install -UI git+https://github.com/openstack/python-magnumclient
Para gerenciar objetos Kubernetes, você precisa do cliente do console kubectl . Os métodos de instalação para vários sistemas operacionais são descritos na documentação oficial .
Para criar um cluster, você precisará criar ou usar os existentes:
- Modelo de cluster;
- Um conjunto de parâmetros para a CPU e RAM de máquinas virtuais ( sabor ).
Você pode criar um modelo de cluster e criar um sabor próprio ou usar modelos públicos pré-criados.
Você também precisará determinar a zona de disponibilidade, o tipo de discos para o cluster e o número de nós. Vale considerar que ainda não suportamos a possibilidade de criar um cluster em várias zonas. Você pode escolher qualquer tipo de unidade de rede (rápida, universal ou básica).
Você pode aprender mais sobre os tipos de unidades em nossa base de conhecimento .
O número de nós pode ser diferente para funções mestre e subordinado . Nos nós que executam a função principal, os elementos de controle do cluster serão ativados - controller-manager , scheduler , api . Nos outros nós, os serviços kubelet , kube-proxy e todos os contêineres de aplicativos serão lançados. Você pode aprender mais sobre os componentes que são executados nos nós do cluster na documentação oficial .
Para acessar nós via SSH, você precisará usar a chave SSH criada anteriormente. Os comandos de amostra usarão uma chave chamada ssh-test .
Usaremos o modelo e o sabor do cluster público, o tipo de disco rápido e a zona de disponibilidade do ru-1b .
Em nosso cluster, 2 nós principais e 3 nós minion serão inicializados inicialmente.
Para verificar esses parâmetros, usamos os comandos openstackclient e o arquivo de acesso baixado ( rc.sh ):
Por exemplo, escolheremos o segundo modelo de cluster; endereços flutuantes publicamente acessíveis para cada um dos nós não serão criados a partir dele. Nós não precisaremos deles.
# Kubernetes test-cluster # keypair , $ openstack coe cluster create \ --cluster-template kubernetes-nofloatingips-ru-1b-v1.9.9 \ --master-count 2 \ --node-count 3 \ --keypair ssh-test \ --master-flavor BL1.2-4096 \ --flavor BL1.2-4096 \ test-cluster
Observe que nós escolhemos a mesma configuração para nós diferentes (parâmetros de sabor principal e sabor), você pode escolher diferentes conjuntos de configurações, dependendo dos requisitos do cluster. Sua mudança é possível após a sua criação.
Também vale a pena considerar que, ao criar um cluster com vários nós principais, um balanceador de carga será criado automaticamente para acessar a API do Kubernetes.
Após alguns minutos, um cluster Kubernetes aparecerá no seu projeto. No painel de controle do projeto, você verá novas máquinas virtuais, discos e objetos de rede.
Você pode verificar o status do seu cluster através do openstackclient:
openstack coe cluster list -c name -c status +--------------+--------------------+ | name | status | +--------------+--------------------+ | test-cluster | CREATE_IN_PROGRESS | +--------------+--------------------+
Depois que o cluster entra no estado CREATE_COMPLETE, você pode gerenciar seus objetos através do utilitário kubectl baixando o arquivo de configuração usando os seguintes comandos:
$ mkdir -p ~/test-cluster $ openstack coe cluster config test-cluster --dir ~/test-cluster
Depois disso, você pode trabalhar com o cluster usando o utilitário kubectl:
$ export KUBECONFIG=~/test-cluster/config $ kubectl get pods --all-namespaces -o=custom-columns=NAME:.metadata.name,STATUS:.status.phase NAME STATUS coredns-785dcf9c58-6gnfp Running heapster-6846cdc674-rm4k6 Running kube-dns-autoscaler-6b94f7bbf8-x5clt Running kubernetes-dashboard-747575c864-wlg6p Running monitoring-grafana-84b4596dd7-zf5rx Running monitoring-influxdb-c8486fc95-bqqb6 Running node-exporter-test-cluster-robvp4cvwpt7-minion-0 Running
Se necessário, você pode aumentar ou diminuir o número de nós minion no cluster por meio do openstackclient passando o novo valor node_count:
$ openstack coe cluster update test-cluster replace node_count=4
Principais objetos de cluster do Kubernetes
Pods
Embora o Kubernetes gerencie um conjunto de contêineres, a entidade subjacente que o Kubernetes gerencia não é um contêiner, mas um Pod .
Pod é um conjunto de namespaces do kernel do Linux e configurações de pilha de rede que permitem montar um conjunto de contêineres em uma única entidade.
Na maioria das vezes, um contêiner com o aplicativo é iniciado dentro de um Pod separado.
Se necessário, você pode executar vários contêineres dentro de um Pod, isso pode ser útil quando você precisar fornecer acesso de um contêiner para outro por meio da interface de rede localhost ou, por algum outro motivo, executar vários contêineres no mesmo host.
Todos os contêineres em execução no mesmo Pod terão um nome de host, endereço IP, tabela de roteamento e discos.
É importante notar que, ao dimensionar o número de instâncias do seu aplicativo no Kubernetes, é necessário aumentar o número de Pods, e não o número de contêineres em um Pod específico.
Mais detalhes na documentação oficial dos pods .
Por exemplo, vamos criar o Pod mais simples com o Nginx usando a descrição no formato yaml:
Para criar um Pod, podemos usar o utilitário kubectl .
Adicionamos todos os exemplos apresentados no artigo ao nosso grupo Github , para que você não possa criar arquivos no seu computador, mas use o URL do arquivo do repositório público:
$ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/pods/nginx-basic.yaml
Após a criação, podemos solicitar informações completas sobre o status do Pod usando o comando kubectl description:
$ kubectl describe pod nginx Name: nginx Namespace: default Node: test-cluster-nd5c5y6lsfxb-minion-0/10.0.0.5 Start Time: Sun, 17 Jun 2018 12:29:03 +0000 Labels: <none> Annotations: <none> Status: Running IP: 10.100.88.9 Containers: nginx: Container ID: docker://6ca6383b66686c05c61c1f690737110e0f8994eda393f44a7ebfbbf2b2026267 Image: library/nginx:1.14-alpine Image ID: docker-pullable://docker.io/nginx@sha256:944b79ca7dbe456ce72e73e70816c1990e39967c8f010349a388c00b77ec519c Port: 80/TCP Host Port: 0/TCP State: Running Started: Sun, 17 Jun 2018 12:29:16 +0000 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-rp5ls (ro) Conditions: Type Status Initialized True Ready True PodScheduled True Volumes: default-token-rp5ls: Type: Secret (a volume populated by a Secret) SecretName: default-token-rp5ls Optional: false QoS Class: BestEffort Node-Selectors: <none> Tolerations: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 52s default-scheduler Successfully assigned nginx to test-cluster-nd5c5y6lsfxb-minion-0 Normal SuccessfulMountVolume 51s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 MountVolume.SetUp succeeded for volume "default-token-rp5ls" Normal Pulling 50s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 pulling image "library/nginx:1.14-alpine" Normal Pulled 39s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 Successfully pulled image "library/nginx:1.14-alpine" Normal Created 39s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 Created container Normal Started 39s kubelet, test-cluster-nd5c5y6lsfxb-minion-0 Started container
Como você pode ver, o Pod foi iniciado em um nó chamado test-cluster-nd5c5y6lsfxb-minion-0 e recebeu um endereço IP interno de 10.100.88.9.
Na seção Eventos, você pode ver os principais eventos de inicialização - selecionando um nó para iniciar e fazer o download da imagem.
Podemos entrar no Pod e verificar o status dos processos dentro do contêiner:
$ kubectl exec -it nginx sh ps aux PID USER TIME COMMAND 1 root 0:00 nginx: master process nginx -g daemon off; 7 nginx 0:00 nginx: worker process 20 root 0:00 sh 24 root 0:00 ps aux exit
Deve-se ter em mente que o endereço IP 10.100.88.9 não estará disponível para outros aplicativos dentro e fora do cluster Kubernetes; o acesso ao Nginx em execução será possível apenas dentro do próprio Pod:
$ ping -c 1 10.100.88.9 PING 10.100.88.9 (10.100.88.9): 56 data bytes --- 10.100.88.9 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss $ kubectl exec nginx -- ping -c1 10.100.88.9 PING 10.100.88.9 (10.100.88.9): 56 data bytes 64 bytes from 10.100.88.9: seq=0 ttl=64 time=0.075 ms --- 10.100.88.9 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.075/0.075/0.075 ms
Além do fato de o endereço IP especificado estar acessível apenas no contêiner, ele também não é permanente. Isso significa que, se este Pod for recriado, ele poderá obter um endereço IP diferente.
Para resolver esses problemas, você pode usar um objeto chamado Serviço.
Serviços
O serviço permite atribuir endereços IP permanentes para os Pods, fornecer acesso a partir de redes externas e equilibrar solicitações entre os Pods.
Você pode aprender mais sobre o serviço na documentação oficial .
Por exemplo, precisamos remover o Pod em execução:
$ kubectl delete pod nginx
Adicione à descrição do Pod um rótulo (Label), necessário para o Serviço:
Também precisaremos de uma descrição do Serviço:
Crie Pod e Serviço:
$ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/pods/nginx-labeled.yaml \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/services/nginx-nodeport.yaml
Como o Serviço criado é do tipo NodePort, a porta 30001 indicada por nós em todas as interfaces de rede será aberta em todos os nós do cluster.
Isso significa que, se adicionarmos um endereço IP externo a qualquer nó, podemos acessar o Pod em execução com o Nginx a partir de uma rede externa.
Para não usar os endereços externos dos nós do cluster para acessar o Serviço, podemos usar o tipo LoadBalancer em vez de NodePort.
Vamos precisar de uma nova descrição do serviço:
Exclua o serviço atual e aplique a nova descrição:
$ kubectl delete service nginx-service $ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/services/nginx-loadbalancer.yaml
Depois de iniciar o serviço, o Nginx estará disponível na porta TCP 80 a partir de uma rede externa e não será necessário atribuir e usar endereços externos para os nós do cluster. O serviço do tipo LoadBalancer alocará automaticamente um novo endereço externo para o seu projeto VPC e começará a usá-lo.
Você pode obter informações sobre o endereço externo destacado usando o kubectl:
$ kubectl get service nginx-service -o=custom-columns=IP:status.loadBalancer.ingress[0].ip IP xxx.xxx.xxx.xxx
Nos nossos exemplos, apenas um Pod foi lançado com o Nginx. Para dimensionar o aplicativo para mais pods, podemos usar a implantação.
Implantações
A implantação é a essência do cluster Kubernetes, que permite dimensionar os Pods e atualizar ou reverter convenientemente as versões para um grande número de Pods.
Em vez de Implantação, você também pode usar o objeto ReplicaSet, mas não o tocaremos em nossos exemplos.
Você pode aprender mais sobre implantação na documentação oficial .
Novamente, precisamos remover o Pod (não precisamos remover o Serviço):
$ kubectl delete pod nginx
Adicione a seguinte descrição de implantação:
Crie a implantação especificada:
$ kubectl create -f \ https://raw.githubusercontent.com/selectel/kubernetes-examples/master/deployments/nginx-1.14.yaml
Escolhemos 10 para o parâmetro replicas, para que 10 Pods com o aplicativo Nginx sejam criados em nosso cluster:
$ kubectl get pods --selector app=webservice NAME READY STATUS RESTARTS AGE nginx-deployment-54bfdc4489-42rrb 1/1 Running 0 4m nginx-deployment-54bfdc4489-5lvtc 1/1 Running 0 4m nginx-deployment-54bfdc4489-g7rk2 1/1 Running 0 4m nginx-deployment-54bfdc4489-h5rxp 1/1 Running 0 4m nginx-deployment-54bfdc4489-l9l2d 1/1 Running 0 4m nginx-deployment-54bfdc4489-pjpvg 1/1 Running 0 4m nginx-deployment-54bfdc4489-q8dnp 1/1 Running 0 4m nginx-deployment-54bfdc4489-s4wzf 1/1 Running 0 4m nginx-deployment-54bfdc4489-tfxf9 1/1 Running 0 4m nginx-deployment-54bfdc4489-xjzb5 1/1 Running 0 4m
Você pode acessar o aplicativo em execução na rede externa usando o Serviço criado na seção anterior. O serviço equilibrará automaticamente as solicitações da rede externa entre 10 instâncias do Nginx.
Se necessário, podemos atualizar a versão do Nginx. Atualize a descrição de Implantação, alterando a versão da imagem de 1,14-alpino para 1,15-alpino:
Para iniciar o processo de atualização dos Pods, usamos o comando kubectl. Preste atenção ao argumento --record, é útil para a conveniente reversão subsequente da versão do Nginx:
$ kubectl apply -f \ https://raw.githubusercontent.com/selectel/kubernetes-examples/master/deployments/nginx-1.15.yaml \ --record
Você pode monitorar o andamento da atualização usando o seguinte comando:
$ kubectl rollout status deployment nginx-deployment Waiting for rollout to finish: 4 out of 10 new replicas have been updated...
O Kubernetes aguardará 10 segundos após uma atualização bem-sucedida de um Pod, pois especificamos o valor 10 para o parâmetro minReadySeconds na descrição da Implantação.
Após a conclusão da atualização, todos os Pods for Deployment entrarão em um estado ativo:
$ kubectl get deployment --selector app=webservice NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 10 10 10 10 23m
Podemos reverter a versão do aplicativo se algo der errado. Para fazer isso, precisamos selecionar a revisão de implantação desejada:
$ kubectl rollout history deployment nginx-deployment deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 <none> 2 kubectl apply --filename=https://raw.githubusercontent.com/selectel/kubernetes-examples/master/deployments/nginx-1.15.yaml --record=true
Existem 2 revisões na saída do comando - a primeira é a criação inicial do Deployment, a segunda é uma atualização. Como usamos o argumento --record ao atualizar, vemos o comando que criou a segunda revisão do Deployment.
Para reverter a versão, use o seguinte comando:
$ kubectl rollout undo deployment nginx-deployment --to-revision=1
Da mesma forma com a atualização, podemos monitorar a reversão da versão usando o comando:
$ kubectl rollout status deployment nginx-deployment Waiting for rollout to finish: 6 out of 10 new replicas have been updated…
Em todos os nossos exemplos, usamos contêineres sem um armazenamento de dados persistente. Na próxima seção, vamos corrigi-lo.
Armazenamento de dados
Por padrão, todos os dados dos contêineres em execução nos Pods são efêmeros e serão perdidos quando os Pods falham.
Você pode usar o objeto PersistentVolumeClaim para executar Pods com um data warehouse persistente.
Criar um objeto desse tipo em um cluster é muito simples - basta adicionar sua descrição, semelhante à maneira como criamos Pod, Serviço ou Implantação nas seções anteriores.
Mais informações podem ser encontradas na documentação oficial .
Descrição de exemplo de PersistentVolumeClaim criando um disco de 10 GB:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pv-claim spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi
Podemos conectá-lo como um disco ao nosso Pod atualizando a descrição do Pod com o Nginx criado anteriormente:
No entanto, para que o disco seja criado, você precisará especificar as propriedades do disco criado na forma de StorageClass. No serviço "Nuvem privada virtual", você pode usar unidades de rede de tipos rápido, universal e básico como armazenamento permanente de dados do Kubernetes Pod.
Por exemplo, para criar um StorageClass que permita o uso de discos rápidos na zona de disponibilidade do ru-1b, você precisa da seguinte descrição:
Antes de criar os objetos especificados, exclua a Implantação criada anteriormente:
$ kubectl delete deployment nginx-deployment
Primeiro, vamos criar uma StorageClass, para que ela se torne a classe padrão, e o PersistentVolumeClaim criado posteriormente a usará:
$ kubectl create -f \ https://raw.githubusercontent.com/selectel/kubernetes-examples/master/storageclasses/fast.ru-1b.yaml
Crie PersistentVolumeClaim e Pod:
$ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/persistentvolumeclaims/my-pv-claim.yaml \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/pods/nginx-with-volume.yaml
Depois disso, um disco será criado automaticamente em seu projeto, que será conectado a um dos nós subordinados do cluster. Quando cai, o disco muda automaticamente para outro nó.
Podemos ver o disco dentro do contêiner com o Nginx:
$ kubectl exec -it nginx sh mount | grep "/var/www/html" /dev/sdc on /var/www/html type ext4 (rw,seclabel,relatime,data=ordered) exit
Você pode conectar a unidade ao Deployment. Um exemplo correspondente pode ser encontrado na documentação oficial .
Painel de Controle Kubernetes
Você pode usar o painel interno do próprio Kubernetes para exibir o status dos objetos de cluster e seu gerenciamento.
Para acessar todos os recursos do painel, você precisará criar uma conta com a função de administrador em seu cluster.
Para fazer isso, precisamos de uma descrição da conta:
E descrição da função:
Crie os objetos especificados:
$ kubectl create \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/accounts/admin-user.yaml \ -f https://raw.githubusercontent.com/selectel/kubernetes-examples/master/clusterrolebindings/cluster-admin.yaml
Em seguida, você precisará descobrir o valor do token gerado para esta conta.
Para fazer isso, localize o objeto Secreto correspondente no cluster:
$ kubectl get secret --namespace=kube-system | grep "admin-user-token" admin-user-token-bkfhb kubernetes.io/service-account-token 3 22m
E observe o valor do token do Segredo encontrado com o nome admin-user-token-bkfhb:
$ kubectl describe secret admin-user-token-bkfhb --namespace=kube-system | grep "token:" token: XXXXXX...
Em resposta, você receberá o valor do token, salve-o, será útil para nós no futuro.
Para detalhes de controle de acesso para objetos Kubernetes, consulte a documentação oficial .
Caso você tenha criado um cluster a partir de um modelo público, o Pod e o Serviço já existem nele para garantir a operação do painel:
$ kubectl get svc kubernetes-dashboard --namespace=kube-system 206ms Tue Jun 19 14:35:19 2018 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes-dashboard ClusterIP 10.254.122.245 <none> 443/TCP 2d $ kubectl get pod --namespace=kube-system --selector k8s-app=kubernetes-dashboard 119ms Tue Jun 19 14:36:48 2018 NAME READY STATUS RESTARTS AGE kubernetes-dashboard-747575c864-jpxvt 1/1 Running 0 2d
Como o Serviço é do tipo ClusterIP, ele estará disponível apenas no próprio cluster.
Você pode acessar o painel do seu computador em funcionamento com o arquivo de configuração do cluster usando o comando kubectl:
$ kubectl proxy Starting to serve on 127.0.0.1:8001
Teste o proxy abrindo o endereço especificado no navegador:
Se você encontrar uma resposta semelhante à captura de tela, poderá ir para a tela do painel de controle usando o seguinte endereço:
http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
Passando por isso, você deve ver a tela de login no painel:
Você precisará especificar o token recebido anteriormente. Após o login, você pode usar o painel de controle:
Você pode descobrir todos os recursos do painel de controle na documentação oficial .
Monitorando objetos Kubernetes
Se você usar o modelo de cluster público, executará automaticamente os componentes para coletar e exibir métricas - Prometheus e Grafana.
Da mesma forma que no painel de controle, o ClusterIP é instalado como o tipo de Serviço; o acesso a ele é possível apenas dentro do cluster ou através do proxy kubectl. Você pode acessar o Grafana no seu computador de trabalho no seguinte endereço:
http://127.0.0.1:8001/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana:80
Conclusão
Neste artigo, examinamos os objetos Kubernetes mais usados e analisamos exemplos de como iniciar e gerenciar um cluster usando o OpenStack Magnum.
Num futuro próximo, será possível usar as versões mais recentes do Kubernetes, e o gerenciamento de cluster estará disponível no painel de controle .
Ficaremos contentes se você usar nosso serviço no modo de teste e fornecer feedback.