Essa é a versão completa de impressão dessa seção Clique aqui para imprimir.

Retornar à visualização normal.

Extendendo o Kubernetes

1 - Extendendo a API do Kubernetes

1.1 - Extendendo a API do Kubernetes com a camada de agregação

A camada de agregação permite ao Kubernetes ser estendido com APIs adicionais, para além do que é oferecido pelas APIs centrais do Kubernetes. As APIs adicionais podem ser soluções prontas tal como o catálogo de serviços, ou APIs que você mesmo desenvolva.

A camada de agregação é diferente dos Recursos Personalizados, que são uma forma de fazer o kube-apiserver reconhecer novas espécies de objetos.

Camada de agregação

A camada de agregação executa em processo com o kube-apiserver. Até que um recurso de extensão seja registado, a camada de agregação não fará nada. Para registar uma API, terá de adicionar um objeto APIService que irá "reclamar" o caminho URL na API do Kubernetes. Nesta altura, a camada de agregação procurará qualquer coisa enviada para esse caminho da API (e.g. /apis/myextension.mycompany.io/v1/…) para o APIService registado.

A maneira mais comum de implementar o APIService é executar uma extensão do servidor API em Pods que executam no seu cluster. Se estiver a usar o servidor de extensão da API para gerir recursos no seu cluster, o servidor de extensão da API (também escrito como "extension-apiserver") é tipicamente emparelhado com um ou mais controladores. A biblioteca apiserver-builder providencia um esqueleto para ambos os servidores de extensão da API e controladores associados.

Latência da resposta

Servidores de extensão de APIs devem ter baixa latência de rede de e para o kube-apiserver. Pedidos de descoberta são necessários que façam a ida e volta do kube-apiserver em 5 segundos ou menos.

Se o seu servidor de extensão da API não puder cumprir com o requisito de latência, considere fazer alterações que permitam atingi-lo. Pode também definir portal de funcionalidade EnableAggregatedDiscoveryTimeout=false no kube-apiserver para desativar a restrição de intervalo. Esta portal de funcionalidade deprecado será removido num lançamento futuro.

Qual é o próximo

2 - Extensões de Computação, armazenamento e redes

2.1 - Plugins de rede

Plugins de redes no Kubernetes podem ser dos seguintes tipos:

  • Plugins CNI: Aderentes à especificação Container Network Interface (CNI), desenhados para interoperabilidade.
    • Kubernetes usa a versão v0.4.0 da especificação CNI.
  • Plugin kubenet: Implementa o cbr0 básico usando os plugins CNI bridge e host-local

Instalação

O kubelet possui um plugin único padrão, e um plugin padrão comum para todo o cluster. Ele verifica o plugin quando inicia, se lembra o que encontrou, e executa o plugin selecionado em momentos oportunos dentro do ciclo de vida de um Pod (isso é verdadeiro apenas com o Docker, uma vez que o CRI gerencia seus próprios plugins de CNI). Existem dois parâmetros de linha de comando no Kubelet para se ter em mente quando usando plugins:

  • cni-bin-dir: O Kubelet verifica esse diretório por plugins na inicialização
  • network-plugin: O plugin de rede que deve ser utilizado do diretório configurado em cni-bin-dir. Deve ser igual ao nome configurado por um plugin no diretório de plugins. Para plugins de CNI, isso equivale ao valor cni.

Requisitos de plugins de Rede

Além de prover a interface NetworkPlugin para configuração da rede do pod, o plugin pode necessitar de suporte específico ao kube-proxy. O proxy iptables obviamente depende do iptables, e o plugin deve garantir que o tráfego do contêiner esteja disponível para o iptables. Por exemplo, se o plugin conecta os contêineres à Linux bridge, o plugin deve configurar a diretiva de sysctl net/bridge/bridge-nf-call-iptables com o valor 1 para garantir que o proxy iptables opere normalmente. Se o plugin não faz uso da Linux Bridge (mas outro mecanismo, como Open vSwitch) ele deve garantir que o tráfego do contêiner é roteado apropriadamente para o proxy.

Por padrão, se nenhum plugin de rede é configurado no kubelet, o plugin noop é utilizado, que configura net/bridge/bridge-nf-call-iptables=1 para garantir que configurações simples (como Docker com bridge Linux) operem corretamente com o proxy iptables.

CNI

O plugin de CNI é selecionado utilizando-se da opção --network-plugin=cni no início do Kubeket. O Kubelet lê um arquivo do diretório especificado em --cni-conf-dir (padrão /etc/cni/net.d) e usa a configuração de CNI desse arquivo para configurar a rede de cada Pod. O arquivo de configuração do CNI deve usar a especificação de CNI, e qualquer plugin referenciado nesse arquivo deve estar presente no diretório --cni-bin-dir (padrão /opt/cni/bin).

Se existirem múltiplos arquivos de configuração no diretório, o kubelet usa o arquivo de configuração que vier primeiro pelo nome, em ordem alfabética.

Adicionalmente ao plugin de CNI especificado no arquivo de configuração, o Kubernetes requer o plugin CNI padrão lo ao menos na versão 0.2.0.

Suporte a hostPort

O plugin de redes CNI suporta hostPort. Você pode utilizar o plugin oficial portmap ou usar seu próprio plugin com a funcionalidade de portMapping.

Caso você deseje habilitar o suporte a hostPort, você deve especificar portMappings capability no seu cni-conf-dir. Por exemplo:

{
  "name": "k8s-pod-network",
  "cniVersion": "0.3.0",
  "plugins": [
    {
      "type": "calico",
      "log_level": "info",
      "datastore_type": "kubernetes",
      "nodename": "127.0.0.1",
      "ipam": {
        "type": "host-local",
        "subnet": "usePodCidr"
      },
      "policy": {
        "type": "k8s"
      },
      "kubernetes": {
        "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
      }
    },
    {
      "type": "portmap",
      "capabilities": {"portMappings": true}
    }
  ]
}

Suporte a controle de banda

Funcionalidade experimental

O plugin de rede CNI também suporta o controle de banda de entrada e saída. Você pode utilizar o plugin oficial bandwidth desenvolvido ou usar seu próprio plugin de controle de banda.

Se você habilitar o suporte ao controle de banda, você deve adicionar o plugin bandwidth no seu arquivo de configuração de CNI (padrão /etc/cni/net.d) e garantir que o programa exista no diretório de binários do CNI (padrão /opt/cni/bin).

{
  "name": "k8s-pod-network",
  "cniVersion": "0.3.0",
  "plugins": [
    {
      "type": "calico",
      "log_level": "info",
      "datastore_type": "kubernetes",
      "nodename": "127.0.0.1",
      "ipam": {
        "type": "host-local",
        "subnet": "usePodCidr"
      },
      "policy": {
        "type": "k8s"
      },
      "kubernetes": {
        "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
      }
    },
    {
      "type": "bandwidth",
      "capabilities": {"bandwidth": true}
    }
  ]
}

Agora você pode adicionar as anotações kubernetes.io/ingress-bandwidth e kubernetes.io/egress-bandwidth em seu pod. Por exemplo:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/ingress-bandwidth: 1M
    kubernetes.io/egress-bandwidth: 1M
...

kubenet

Kubenet é um plugin de rede muito simples, existente apenas no Linux. Ele não implementa funcionalidades mais avançadas, como rede entre nós ou políticas de rede. Ele é geralmente utilizado junto a um provedor de nuvem que configura as regras de roteamento para comunicação entre os nós, ou em ambientes com apenas um nó.

O Kubenet cria uma interface bridge no Linux chamada cbr0 e cria um par veth para cada um dos pods com o host como a outra ponta desse par, conectado à cbr0. Na interface no lado do Pod um endereço IP é alocado de uma faixa associada ao nó, sendo parte de alguma configuração no nó ou pelo controller-manager. Na interface cbr0 é associado o MTU equivalente ao menor MTU de uma interface de rede do host.

Esse plugin possui alguns requisitos:

  • Os plugins CNI padrão bridge, lo e host-local são obrigatórios, ao menos na versão 0.2.0. O Kubenet buscará inicialmente esses plugins no diretório /opt/cni/bin. Especifique a opção cni-bin-dir no kubelet para fornecer um diretório adicional de busca. O primeiro local equivalente será o utilizado.
  • O kubelet deve ser executado com a opção --network-plugin=kubenet para habilitar esse plugin.
  • O Kubelet deve ainda ser executado com a opção --non-masquerade-cidr=<clusterCidr> para garantir que o tráfego de IPs para fora dessa faixa seja mascarado.
  • O nó deve possuir uma subrede associada, através da opção --pod-cidr configurada na inicialização do kubelet, ou as opções --allocate-node-cidrs=true --cluster-cidr=<cidr> utilizadas na inicialização do controller-manager.

Customizando o MTU (com kubenet)

O MTU deve sempre ser configurado corretamente para obter-se a melhor performance de rede. Os plugins de rede geralmente tentam detectar uma configuração correta de MTU, porém algumas vezes a lógica não irá resultar em uma configuração adequada. Por exemplo, se a Docker bridge ou alguma outra interface possuir um MTU pequeno, o kubenet irá selecionar aquela MTU. Ou caso você esteja utilizando encapsulamento IPSEC, o MTU deve ser reduzido, e esse cálculo não faz parte do escopo da maioria dos plugins de rede.

Sempre que necessário, você pode configurar explicitamente o MTU com a opção network-plugin-mtu no kubelet. Por exemplo, na AWS o MTU da eth0 geralmente é 9001 então você deve especificar --network-plugin-mtu=9001. Se você estiver usando IPSEC você deve reduzir o MTU para permitir o encapsulamento excedente; por exemplo: --network-plugin-mtu=8773.

Essa opção faz parte do plugin de rede. Atualmente apenas o kubenet suporta a configuração network-plugin-mtu.

Resumo de uso

  • --network-plugin=cni especifica que devemos usar o plugin de redes cni com os binários do plugin localizados em --cni-bin-dir (padrão /opt/cni/bin) e as configurações do plugin localizadas em --cni-conf-dir (default /etc/cni/net.d).
  • --network-plugin=kubenet especifica que iremos usar o plugin de rede kubenet com os plugins CNI bridge, lo e host-local localizados em /opt/cni/bin ou cni-bin-dir.
  • --network-plugin-mtu=9001 especifica o MTU a ser utilizado, atualmente apenas em uso pelo plugin de rede kubenet

Qual é o próximo

3 - Padrão Operador

Operadores são extensões de software para o Kubernetes que fazem uso de recursos personalizados para gerir aplicações e os seus componentes. Operadores seguem os
princípios do Kubernetes, notavelmente o ciclo de controle.

Motivação

O padrão Operador tem como objetivo capturar o principal objetivo de um operador humano que gere um serviço ou um conjunto de serviços. Operadores humanos responsáveis por aplicações e serviços específicos têm um conhecimento profundo da forma como o sistema é suposto se comportar, como é instalado e como deve reagir na ocorrência de problemas.

As pessoas que executam cargas de trabalho no Kubernetes habitualmente gostam de usar automação para cuidar de tarefas repetitivas. O padrão Operador captura a forma como pode escrever código para automatizar uma tarefa para além do que o Kubernetes fornece.

Operadores no Kubernetes

O Kubernetes é desenhado para automação. Out of the box, você tem bastante automação embutida no núcleo do Kubernetes. Pode usar o Kubernetes para automatizar instalações e executar cargas de trabalho, e pode ainda automatizar a forma como o Kubernetes faz isso.

O conceito de controlador no Kubernetes permite a extensão do comportamento sem modificar o código do próprio Kubernetes. Operadores são clientes da API do Kubernetes que atuam como controladores para um dado Custom Resource

Exemplo de um Operador

Algumas das coisas que um operador pode ser usado para automatizar incluem:

  • instalar uma aplicação a pedido
  • obter e restaurar backups do estado dessa aplicação
  • manipular atualizações do código da aplicação juntamente com alterações como esquemas de base de dados ou definições de configuração extra
  • publicar um Service para aplicações que não suportam a APIs do Kubernetes para as descobrir
  • simular uma falha em todo ou parte do cluster de forma a testar a resiliência
  • escolher um lider para uma aplicação distribuída sem um processo de eleição de membro interno

Como deve um Operador parecer em mais detalhe? Aqui está um exemplo em mais detalhe:

  1. Um recurso personalizado (custom resource) chamado SampleDB, que você pode configurar para dentro do cluster.
  2. Um Deployment que garante que um Pod está a executar que contém a parte controlador do operador.
  3. Uma imagem do container do código do operador.
  4. Código do controlador que consulta o plano de controle para descobrir quais recursos SampleDB estão configurados.
  5. O núcleo do Operador é o código para informar ao servidor da API (API server) como fazer a realidade coincidir com os recursos configurados.
    • Se você adicionar um novo SampleDB, o operador configurará PersistentVolumeClaims para fornecer armazenamento de base de dados durável, um StatefulSet para executar SampleDB e um Job para lidar com a configuração inicial.
    • Se você apagá-lo, o Operador tira um snapshot e então garante que o StatefulSet e Volumes também são removidos.
  6. O operador também gere backups regulares da base de dados. Para cada recurso SampleDB, o operador determina quando deve criar um Pod que possa se conectar à base de dados e faça backups. Esses Pods dependeriam de um ConfigMap e / ou um Secret que possui detalhes e credenciais de conexão com à base de dados.
  7. Como o Operador tem como objetivo fornecer automação robusta para o recurso que gere, haveria código de suporte adicional. Para este exemplo, O código verifica se a base de dados está a executar uma versão antiga e, se estiver, cria objetos Job que o atualizam para si.

Instalar Operadores

A forma mais comum de instalar um Operador é a de adicionar a definição personalizada de recurso (Custom Resource Definition) e o seu Controlador associado ao seu cluster. O Controlador vai normalmente executar fora do plano de controle, como você faria com qualquer aplicação containerizada. Por exemplo, você pode executar o controlador no seu cluster como um Deployment.

Usando um Operador

Uma vez que você tenha um Operador instalado, usaria-o adicionando, modificando ou apagando a espécie de recurso que o Operador usa. Seguindo o exemplo acima, você configuraria um Deployment para o próprio Operador, e depois:

kubectl get SampleDB                   # encontra a base de dados configurada

kubectl edit SampleDB/example-database # mudar manualmente algumas definições

…e é isso! O Operador vai tomar conta de aplicar as mudanças assim como manter o serviço existente em boa forma.

Escrevendo o seu próprio Operador

Se não existir no ecosistema um Operador que implementa o comportamento que pretende, pode codificar o seu próprio. Qual é o próximo você vai encontrar alguns links para bibliotecas e ferramentas que pode usar para escrever o seu próprio Operador cloud native.

Pode também implementar um Operador (isto é, um Controlador) usando qualquer linguagem / runtime que pode atuar como um cliente da API do Kubernetes.

Qual é o próximo