No início desta semana
, ocorreu o próximo lançamento do Kubernetes, que foi apelidado de "angelical",
1,13 . Este nome está associado ao número 113, que
é considerado "angelical" e, de acordo com os desenvolvedores do Kubernetes, simboliza "novos começos, transformação e o fim de um capítulo antes de abrir novos". Sem entrar em uma análise mais aprofundada do simbolismo do que está acontecendo, de acordo com a tradição já estabelecida em nosso blog, relataremos pela sétima vez as principais mudanças na nova versão do Kubernetes, projetada para agradar os engenheiros do DevOps- / SRE que trabalham com este produto.
Como fontes de informação, operamos os dados do
rastreamento de aprimoramentos do Kubernetes ,
da tabela
CHANGELOG -1.13 e questões relacionadas, solicitações pull, propostas de aprimoramento do Kubernetes (KEP).
GA para kubeadm
Um dos principais eventos da versão Kubernetes 1.13 foi o anúncio de um status estável (Disponibilidade Geral, GA) para o utilitário do console
kubeadm . O blog do K8s até dedicou uma
publicação separada a isso . Como muitas pessoas sabem, o kubeadm é uma ferramenta para criar clusters do Kubernetes de acordo com as melhores práticas do projeto, bem como com o suporte mínimo adicional. Uma característica distintiva é que os desenvolvedores se esforçam para mantê-lo compacto e independente do provedor / infraestrutura, sem incluir soluções para problemas como infra-estruturas de provisionamento, soluções de rede de terceiros, complementos (monitoramento, registro etc.), integrações específicas com a nuvem fornecedores.
O status do GA marcou a maturidade do kubeadm nas seguintes áreas:
- interface estável do console que segue a política de obsolescência do Kubernetes: os comandos e sinalizadores apresentados no release do GA devem ser suportados por pelo menos um ano após serem preteridos;
- implementação estável "oculta" devido ao fato de que o cluster é criado por métodos que não serão alterados no futuro próximo: o plano de controle é iniciado com muitos pods estáticos, tokens de autoinicialização são usados para
kubeadm join e ComponentConfig é usado para configurar o kubelet; - esquema de configuração com uma nova API (v1beta1), que permite descrever declarativamente quase todos os componentes do cluster (o GitOps é possível para clusters criados com o kubeadm) - uma atualização para a versão v1 é planejada sem alterações mínimas;
- as chamadas fases (ou interface da caixa de ferramentas ) no kubeadm (
kubeadm init phase ), permitindo escolher quais procedimentos de inicialização serão executados; kubeadm upgrade equipe de kubeadm upgrade garante atualizações de cluster entre as versões 1.10.x, 1.11.x, 1.12.xe 1.13.x (atualizações etcd, API Server, Controller Manager e Scheduler);- instalação segura do etcd por padrão (ele usa TLS em qualquer lugar) com a capacidade de expandir para o cluster HA, se necessário.
Também é possível observar que o kubeadm agora reconhece corretamente o Docker 18.09.0 e suas versões mais recentes. Por fim, os desenvolvedores solicitam aos usuários do kubeadm que façam uma pequena
pesquisa on-line na qual possam expressar seus desejos sobre o uso e o desenvolvimento do projeto.
CoreDNS por padrão
O CoreDNS, que recebeu status estável na versão
Kubernetes 1.11 , foi ainda mais longe e
se tornou o servidor DNS padrão nos K8s (em vez do kube-dns usado até agora). Foi planejado que isso acontecesse a partir da versão 1.12, mas os desenvolvedores se depararam com a necessidade de otimizações adicionais na escalabilidade e no consumo de memória, que foram concluídas apenas na versão atual.
O suporte ao kube-dns continuará "por pelo menos uma próxima versão", mas os desenvolvedores estão falando sobre a necessidade
de começar a migrar para uma solução atualizada agora.
Das alterações relacionadas ao tópico CoreDNS no Kubernetes 1.13, o
plug- in
NodeLocal DNS Cache também pode
ser observado para melhorar o desempenho do DNS. A melhoria é obtida executando um agente nos nós do cluster para o cache DNS, que será acessado diretamente pelos pods desse nó. Por padrão, a função está desativada e, para ativá-la, você deve definir
KUBE_ENABLE_NODELOCAL_DNS=true .
Instalações de armazenamento
Muita atenção nas versões recentes do Kubernetes é dedicada ao trabalho com a
Container Storage Interface (CSI), que começou com a versão alfa do CSI no
K8s 1.9 e continuou com a versão beta na
1.10 ... No entanto, já
escrevemos sobre isso mais
de uma vez . Um novo marco significativo foi alcançado no K8s 1.13: o
suporte ao CSI é declarado estável (GA).
(Diagrama do artigo " Entendendo a interface de armazenamento de contêiner ")Junto com isso, o suporte para a especificação CSI v1.0.0 apareceu e o suporte para versões mais antigas do padrão (0.3 e anterior) foi preterido. Isso significa que os drivers CSI mais antigos exigirão a atualização para o CSI 1.0 (e a mudança para o novo diretório de registro de plug-in do Kubelet) para funcionar no Kubernetes 1.15 e versões anteriores. A propósito, dos próprios drivers, vale a pena observar a
aparência da versão alfa da interface CSI para gerenciar o ciclo de vida dos volumes do AWS EBS (Elastic Block Store).
Uma nova adição ao gerenciador de complementos agora instala automaticamente o CRI a partir do CSI se pelo menos um dos dois portões de recursos estiver ativado:
CSIDriverRegistry e
CSINodeInfo . Ele tem o status da versão alfa, mas na verdade é apenas uma solução temporária para o problema, descrita em detalhes como
um mecanismo de instalação do CRD .
O planejamento de volume com base na topologia (
Topology Aware Volume Scheduling ), sobre o qual falamos no contexto da
versão 1.10 do
Kubernetes , tornou-
se estável . Em resumo, o planejador em seu trabalho leva em consideração as limitações da topologia do volume do pod (por exemplo, sua zona e nó).
A
oportunidade introduzida no
Kubernetes 1.9 de usar
dispositivos brutos de bloco (não de rede) como Volumes Persistentes
foi traduzida para beta e agora está ativada por padrão.
Concluímos o tópico de armazenamento com o fato de que o suporte ao GCERegionalPersistentDisk é
declarado estável.
Nós de cluster
A versão alfa do
suporte para plug-ins de monitoramento de dispositivos de terceiros foi introduzida. A idéia por trás dessa iniciativa é trazer para
a árvore o conhecimento específico do dispositivo da Kubelet. Os administradores de cluster receberão métricas relatadas pelos plug-ins de dispositivos no nível do contêiner, e os fabricantes poderão criar essas métricas sem precisar fazer alterações no núcleo do Kubernetes. Detalhes da implementação podem ser encontrados na proposta, chamada
API Kubelet Metadata .
Declarado estável, o
Kubelet Plugin Watcher (também conhecido como Kubelet Device Plugin Registration) permite que plug-ins no nível do nó (plug-ins de dispositivo, CSI e CNI) se comuniquem com o Kubelet sobre si mesmos.
Um novo recurso no status alfa é o
NodeLease . Se anteriormente a "pulsação" de um nó fosse determinada pelo NodeStatus, com um novo recurso, cada nó
kube-node-lease um objeto
Lease associado a ele (no espaço de nome
kube-node-lease ), que é atualizado periodicamente pelo nó. “Pulse” agora é definido pelos dois parâmetros: o antigo NodeStatus, que é relatado ao mestre apenas em caso de alterações ou por um tempo limite fixo (por padrão, é uma vez por minuto) e um novo objeto (é atualizado com freqüência). Como esse objeto é muito pequeno, ele aprimora muito a escalabilidade e o desempenho. Os autores começaram a criar um novo "pulso" depois de testar clusters com um tamanho superior a 2.000 nós, que durante o trabalho poderiam estar contra os limites do etcd, para obter mais detalhes, consulte
KEP-0009 .
type Lease struct { metav1.TypeMeta `json:",inline"` // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata // +optional ObjectMeta metav1.ObjectMeta `json:"metadata,omitempty"` // Specification of the Lease. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status // +optional Spec LeaseSpec `json:"spec,omitempty"` } type LeaseSpec struct { HolderIdentity string `json:"holderIdentity"` LeaseDurationSeconds int32 `json:"leaseDurationSeconds"` AcquireTime metav1.MicroTime `json:"acquireTime"` RenewTime metav1.MicroTime `json:"renewTime"` LeaseTransitions int32 `json:"leaseTransitions"` }
(A especificação compacta do novo objeto para representar o "pulso" do nó - Lease - é idêntica ao LeaderElectionRecord )Segurança
A versão alfa do
Dynamic Audit Control segue as idéias do Dynamic Admission Control e fornece uma configuração dinâmica de recursos avançados de auditoria - para isso, agora você pode registrar (dinamicamente) um webhook que receberá um fluxo de eventos. A necessidade desse recurso é explicada pelo fato de a auditoria do Kubernetes oferecer recursos muito poderosos, mas eles são difíceis de configurar e todas as alterações na configuração ainda exigem uma reinicialização do apiserver.
A criptografia de dados no etcd (consulte a documentação oficial ) foi transferida do status experimental para o beta.
kind: EncryptionConfiguration apiVersion: apiserver.config.k8s.io/v1 resources: - resources: - secrets providers: - identity: {} - aesgcm: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - aescbc: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - secretbox: keys: - name: key1 secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
(Um exemplo de configuração com dados criptografados é obtido da documentação .)Entre as inovações menos significativas nesta categoria:
- Agora o apiserver pode ser configurado para recusar solicitações que não podem entrar nos logs de auditoria.
PodSecurityPolicy objetos PodSecurityPolicy adicionados com suporte à regra MayRunAs para as opções fsGroup e supplementalGroups , que permite definir o intervalo de identificadores de grupo permitidos (GIDs) para pods / containers sem forçar o GID padrão. Além disso, com o PodSecurityPolicy , a estratégia RunAsGroup agora é possível na especificação de RunAsGroup , ou seja, Você pode controlar o GID principal para contêineres.- Para o kube-scheduler, substituímos a porta insegura anterior (10251) pela nova porta segura (10259) e a ativamos por padrão. Se nenhum sinalizador adicional for especificado, após o carregamento, certificados autoassinados serão criados para ele na memória.
CLI
O
kubectl diff ,
mostrando a diferença entre a configuração local e a descrição atual do objeto de trabalho (funciona e recursivamente para diretórios com configurações), recebeu o status beta.
De fato, o
diff "prediz" as alterações que serão feitas com o
kubectl apply , e outro novo recurso é
usado - o
APIServer DryRun . Sua essência - início inativo - deve ser clara a partir do nome, e uma descrição mais detalhada está disponível na
documentação do
Kubernetes . A propósito, na versão 1.13, a função DryRun também foi "atualizada" para a versão beta e ativada por padrão.
E outro avanço para a versão beta no mundo dos console do Kubernetes afetou o
novo mecanismo de plug-in . No caminho, eles
corrigiram a ordem de saída dos plugins (
kubectl plugin list de plugins do
kubectl plugin list ), removendo a classificação adicional de lá.
Além disso, a saída dos recursos de
armazenamento efêmero usados foi
adicionada ao
kubectl describe node e os volumes do tipo
projetado foram adicionados ao
kubectl describe pod .
Outras mudanças
A função do agendador de
Despejo Baseado em Taint foi convertida para o status beta e é ativada por padrão após uma
longa pausa no desenvolvimento. Seu objetivo é adicionar automaticamente
taints aos nós (via NodeController ou kubelet) após a ocorrência de determinadas condições, como, por exemplo,
node.kubernetes.io/not-ready , que corresponde ao valor
NodeCondition em
Ready=False .
Uma anotação de pods críticos para a operação do cluster -
critical-pod - foi descontinuada. Em vez disso, propõe-se usar
prioridades (em versão beta com o Kubernetes 1.11) .
Para a AWS pela primeira vez (como parte das versões alfa), o seguinte ficou disponível:
- integração do AWS ALB (Application Load Balancer) com os recursos do Kubernetes Ingress - aws-alb-ingress-controller (o projeto foi originalmente criado pelo Ticketmaster e CoreOS para migrar o primeiro para a nuvem da AWS);
- O CCM (Cloud Controller Manager) externo da AWS - cloud-provider-aws , responsável por iniciar os controladores com a funcionalidade de provedor específico de nuvem (AWS).
O SIG Azure implementou suporte adicional ao Disco do Azure (Ultra SSD, SSD padrão e arquivos Premium do Azure) e promoveu os
nós do grupo de recursos cruzados para beta. Além disso, os plugins CNI para Windows agora têm
a capacidade de configurar o DNS em um contêiner.
Compatibilidade
- A versão etcd é 3.2.24 (não mudou desde o Kubernetes 1.12).
- As versões verificadas do Docker - 1.11.1, 1.12.1, 1.13.1, 17.03, 17.06, 17.09, 18.06 (também não foram alteradas).
- Ir versão - 1.11.2, coincide com o mínimo suportado.
- A versão CNI é 0.6.0.
- A versão CSI é 1.0.0.
- A versão CoreDNS é 1.2.6.
PS
Leia também em nosso blog: