Container Infra (Kubernetes)
Gerenciando Instâncias de Container Infra
Acessar o painel da NNumbers Cloud
No menu à esquerda, clicar em Container Infra -> Clusters
Na página seguinte, temos a opção para gerenciar os clusters criados anteriormente. É possível iniciar um novo cluster clicando em + Create Cluster (item 1), remover um cluster sem uso (item 2) ou administrar o cluster (item 3).

Após ter iniciado um cluster, você pode, fazer o download do certificado da Autoridade Certificadora (CA) do cluster, assinar um certificado SSL (opção Sign Certificate), redimensionar o tamanho do cluster (opção Resize Cluster) ou atualizar o cluster (opção Rolling _cluster_ Upgrade).
Criação de Clusters Kubernetes
Com base no tutorial Gerenciando instâncias de Container Infra, clique no botão + Create Cluster. Será aberto um formulário onde preenchemos as seguintes informações:
Detalhes do Cluster
Cluster Name - Digite um nome para o cluster
Cluster Template - Selecione um template para o tipo de cluster Kubernetes a ser criado.
Availability Zone - Selecione a zona de disponibilidade.
Keypair - Selecione a chave pública criada anteriormente, ver tutorial Tutorial de Pares de Chave / Key Pair
Addon software (opcional):
- Kubernetes Dashboard - Instala o Kubernetes Dashboard.
- Monitoring - Instala Grafana, Alertmanager, Loki e Prometheus
Após preencher o formulário, no menu à esquerda, clique em Size (item 2)

Dimensionamento do Cluster
Na tela seguinte precisaremos preencher algumas informações sobre o tamanho do cluster.
Antes de iniciar verifique se você tem quotas disponíveis para as configurações selecionadas.

- Numbers of Control Plane Nodes: Quantidade de nós de control plane do Kubernetes para o cluster. Podendo ser os valores 1, 3, 5 e 7 (requisito do algoritmo de consenso (Raft) do etcd (banco de dados do Kubernetes).
Control plane de 1 nó não há alta disponibilidade (sendo usado normalmente apenas para pequenos testes). Se você não tiver referências, recomendamos que inicie com 3 nós. Acima de 7 nós implica em degradação de performance do etcd (banco de dado do Kubernetes) e por consequência no funcionamento das APIs do Kubernetes.
- Flavor of Control Plane Nodes: Selecione qual será o perfil de recursos de (quantidade CPU, quantidade de memória, arquitetura de hardware, etc) que cada nó de control plane do cluster Kubernetes receberá.
Por motivos de requisitos de performance necessários para o etcd (banco de dados do Kubernetes), recomendamos que seja utilizado um flavor Intel com mínimo 2 vCPUs e 8 GB de RAM (i.b2-8) para os nós de control plane.
Worker Nodes
- Number of Worker Nodes - Quantidade inicial de nós de trabalho (workers).
- Flavor of Worker Nodes - Selecione qual será o perfil de recursos de (quantidade CPU, quantidade de memória, arquitetura de hardware, etc) que cada nó de trabalho (worker) do cluster receberá.
Recomendamos no mínimo 2 vCPUs e 4 GB de RAM para os nós de trabalho
A opção Auto-scale Worker Nodes permite que o cluster tenha um tamanho estático ou dinâmico e possa crescer conforme a demanda. Caso deseje que o cluster cresça conforme demanda, marque a opção Auto-scale Worker Nodes e preencha:
- Minimum Number of Worker Nodes: Tamanho mínimo do cluster quando estiver fora do período de alta demanda, com o mínimo ou nenhum recurso em uso. Considere que este campo também define o número inicial de nós de trabalho (workers).
- Maximum number of Worker Nodes: Tamanho máximo de nós de trabalho que o cluster poderá ter quando estiver com muita demanda de processamento.

Rede
tela seguinte, definiremos as configurações de redes para o cluster.

Network
- Create New Network: Selecione se você deseja criar uma nova rede para o cluster. Caso seja desselecionada, outras duas caixas de seleção serão exibidas as caixas de seleção para rede e sub-rede.
Caso a opção criar nova rede (“New Network”) tenha sido selecionada, é necessário que você tenha quota disponível para a criação de além de mais uma rede e uma sub-rede também para a criação de um roteador.
- Use an Existing Network: Selecione a rede para filtrar as sub-rede.
- Use an Existing Subnet: Selecione a sub-rede.
Kubernetes API Loadbalancer
- Allowed CIDRs (opcional): Quando informado irá restringir o acesso às APIs do cluster somente para a rede de gerenciamento da NNumbers Cloud (para instalação do cluster e addons) e para as redes ou IPs informados neste campo. Caso queira informar mais de um CIDR, usar vírgula como separador. Se não informado, o acesso será apenas para a rede de gerenciamento da cloud. Se informado 0.0.0.0/0, ficará acessível para a Internet.
Ingress
- Ingress Controller: Selecione a opção “NNumbers Cloud Native Ingress”, para que seja possível expor a(s) aplicaç(ão)(ões) para a internet. Com essa opção selecionada para cada novo ingress do tipo informado em Configuração de Acesso Externo ao Cluster via Criação de Kubernetes Ingress será criado um novo load balancer no seu ambiente.
Caso nenhuma opção seja selecionada, ainda é possível instalar futuramente algum ingress como nginx ou traefik, entretanto, será necessário o controle do tráfego externo manualmente.
Gerenciamento
Na próxima tela, iremos definir se o cluster deverá se recuperar automaticamente em caso de falhas. Para isso marque a opção Automatically Repair Unhealthy Nodes.

Avançado
Nesta tela é possível sobrepor alguns valores previamente estabelecidos

Nesse passo do wizard, atualmente é possível configurar as seguintes opções avançadas:
| Label | ||
|---|---|---|
| boot_volume_size | <número-inteiro> | Tamanho do volume de boot em gigabytes do sistema operacional fedora-cores. Tamanho padrão é 64 (GB). |
| etcd_volume_size | <número-inteiro> | Tamanho do volume de armazenamento dos dados do etcd (banco de dados do control plane do Kubernetes) em gigabytes do sistema operacional fedora-cores. Tamanho padrão é 5 (GB). |
Após preenchido o campo Additional Labels será apresentado o checkbox I do want to override Template and Workflow Labels, deixe-o em branco. Neste caso será feito uma combinação dos valores que existiam com os valores informados.
Submetendo para criação
Após preencher as informações necessárias, o botão Submit será habilitado, clique nele e observe que o tempo de criação do cluster pode variar conforme a quantidade de nós, tamanho das instâncias computacionais, características selecionadas (e.g. instalação ou não de dashboard, auto-healing, auto-scaling, etc.). Entretanto, após a conclusão da instalação o cluster será exibido na lista de cluster conforme imagem abaixo:

Obtendo o endereço das APIs do cluster Kubernetes
Existe mais de uma maneira de obter o endereço das APIs do cluster Kubernetes, abaixo vamos abordar primeiramente a forma de obter o endereço visualmente pelo console administrativo da NNumbers Cloud. Em seguida abordaremos como obter a configuração no tópico Acessando o Cluster Infra (Kubernetes)
Com base no tutorial Gerenciando instâncias de Container Infra, localize o cluster desejado e clique no nome:

Na tela seguinte, localize e copie o endereço exibido em API Address.

Assinatura e renovação de certificados
Para renovar os certificados ou configurar o cluster com suas próprias autoridades certificadoras e requisição de certificados é possível enviar os arquivos de CA e CSR e a seguir obter a o arquivo de certificado assinado e obter o arquivo de configuração do cluster com a nova CA e novo certificado assinado, os quais posteriormente podem ser usados das formas demonstradas em Acessando o Cluster.
Os passos a seguir demonstram como criar uma CA e assinar um certificado.
Gerar uma chave RSA
openssl genrsa -out CLUSTER_KUBERNETES_key.pem 4096
Criar a configuração do certificado cliente
cat > cliente.conf << END
[req]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[req_distinguished_name]
CN = admin
O = system:masters
OU=MINHA UNIDADE ORGANIZACIONAL
C=BR
ST=SP
L=Sao Paulo
[req_ext]
extendedKeyUsage = clientAuth
END
Gerando o certificado do cliente com base na configuração criada anteriormente
openssl req -new -days 365 \
-config cliente.conf \
-key CLUSTER_KUBERNETES_key.pem \
-out CERTIFICADO_CLIENTE.csr
Após gerar o certificado (CERTIFICADO_CLIENTE.csr), precisamos importar para o cluster. Para isso é necessário assinar o certificado conforme o tópico a seguir.
Assinatura do certificado
Após criar o certificado do cliente (client certificate) é necessário assiná-lo. Para isso, localize o cluster e a direita, clique na “seta” para baixo para exibir o menu (1).
No menu, clique em “Sign Certificate” (2).

Na nova janela aberta, é possível carregar o certificado a partir de um arquivo (item 1) ou copiar e colar o certificado (item 2).
Após Carregar o certificado, no rodapé, clique no botão Sign Certificate (item 3)

Após enviar o certificado, o download do certificado do cliente assinado ocorrerá automaticamente seguindo o formato <NOME_DO_CLUSTER>_cert.pem.
Download do certificado de autoridade certificadora
Clique em Show Certificate, e salve em seu computador.

Após baixar e salvar o certificado da autoridade certificadora do cluster ele será salvo com seguindo o formato <NOME_DO_CLUSTER>_ca.pem.
Acessando o Cluster Infra (Kubernetes)
O acesso ao cluster pode ser feito de duas maneiras:
- Através do download do arquivo de configuração com os arquivos embebidos;
- Através da reconstrução do arquivo de configuração de acesso ao Kubernetes obtendo-se os certificados e endereço do cluster.
Através da opção Get Cluster Config

Clique no menu do cluster desejado (1) e em seguida clique em Get Cluster Config (2) e aguarde o download do arquivo.
A seguir para acessar o cluster
kubectl --kubeconfig <ARQUIVO-DE-CONFIG-CLUSTER-BAIXADO> <comandos-k8s>
e.g.
kubectl --kubeconfig demo-cluster_config get pods
Criar a configuração de acesso do cluster
kubectl config set-cluster <MEU_CLUSTER> \
--server=<ENDERECO_API_CLUSTER> \
--embed-certs \
--certificate-authority=<CERTIFICADO_CA>
Onde:
- <MEU_CLUSTER> é o nome do cluster que será utilizado para a configuração
- <ENDERECO_API_CLUSTER> pode ser obtido com base no tutorial Obtendo o endereço da API do cluster Kubernetes
- <CERTIFICADO_CA> é o certificado da autoridade certificadora do cluster, baixado em Download do certificado de autoridade certificadora, onde o nome é
<NOME_DO_CLUSTER>_ca.pem.
Configurar as credenciais
kubectl config set-credentials admin \
--certificate-authority=<CERTIFICADO_CA> \
--client-key=CLUSTER_KUBERNETES_key.pem \
--client-certificate=<CERTIFICADO_CLIENTE_ASSINADO> \
--embed-certs=true
Onde:
- <CERTIFICADO_CA> é o certificado da autoridade certificadora do cluster, baixado em Download do certificado de autoridade certificadora, onde o nome é
<NOME_DO_CLUSTER>_ca.pem. - CLUSTER_KUBERNETES_key.pem é a chave gerada em Gerar uma chave RSA
- <CERTIFICADO_CLIENT_ASSINADO> é o certificado baixado em Assinatura do certificado que segue o formato
<NOME_DO_CLUSTER>_cert.pem.
Configurar o contexto
kubectl config set-context <MEU_CLUSTER>_admin \
--cluster=<MEU_CLUSTER> --user=admin
Selecionar o contexto como contexto atual
kubectl config use-context <MEU_CLUSTER>_admin
Visualizar a configuração criada
kubectl config view
Criação de Volumes Persistentes para os Pods
Para criar volumes persistentes para os Pods, vamos utilizar o tutorial Acessando o Cluster Infra (Kubernetes) como base para configuração de acesso ao cluster via a ferramenta de linha de comando kubectl.
Para a criação de volumes persistentes é necessário a configuração de uma storage classe que permitirá a criação/acesso de volumes (block storage) nativos NNumbers Cloud. Logo, crie um arquivo chamado nnumbers-cloud-sc.yaml com o conteúdo:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nnumbers-cloud-sc
annotations:
storageclass.beta.kubernetes.io/is-default-class: "true"
provisioner: cinder.csi.openstack.org
A linha storageclass.beta.kubernetes.io/is-default-class: "true" define a storage class one-cloud-sc como padrão. Portanto, a partir dessa configuração, será opcional informar a storage class para a criação das persistent volume claims (definição do volume para o Kubernetes). Sendo que a omissão desta linha obriga que na criação dos persistent volume claims seja a storage class name (storageClassName).
Instalar a storage class executando o comando:
kubectl apply -f nnumbers-cloud-sc.yaml
Verificar se foi instalado corretamente com o comando:
kubectl get sc
O retorno do comando acima deverá ser algo como:
O exemplo abaixo irá criar um volume nativo NNumbers Cloud de 1GB através do persistent volume claim teste-pvc e disponibilizá-lo para o pod a seguir nomeado nginx com o nome teste-volume e será montado no ponto de montagem /var/lib/www/html.
Podemos realizar um teste com o seguinte manifesto (teste-storage.yaml)
#### Alocar o volume de 1GB com o nome de teste-pvc
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: teste-pvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: nnumbers-cloud-sc
resources:
requests:
storage: 1Gi
---
#### Criar pod do Nginx utilizando o volume alocado
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: nginx
ports:
- containerPort: 80
protocol: TCP
#### Montar o disco alocado no caminho /var/lib/www/html dentro do POD
volumeMounts:
- mountPath: /var/lib/www/html
name: teste-volume
volumes:
- name: teste-volume
persistentVolumeClaim:
claimName: teste-pvc
readOnly: false
A linha storageClassName: nnumbers-cloud-sc é opcional conforme informada acima.
Teremos a seguinte resposta:
Verificando se tudo funcionou conforme esperado:
- Verificar se o volume foi criado corretamente
kubectl get pvc
Retorno:
- Verificar se houve o deploy do nginx
kubectl get pods -n default
Retorno:
- Verificar se o nginx está usando o disco:
kubectl exec -it nginx -n default -- df -h
Retorno:

- Após os testes podemos remover o deploy executando:
kubectl delete -f teste-storage.yaml -n default
Teremos uma resposta como:
Próximos passos
Esta página ajudou?
Reportar um problema nesta páginaNão envie senhas, chaves, tokens ou dados de clientes.