O Kubernetes 1.11 foi lançado na
quarta -
feira . Continuamos nossa tradição e falamos sobre as mudanças mais significativas, com base nos dados do
CHANGELOG-1.11 e em vários problemas, solicitações de recebimento e propostas de design. O que há de novo no K8s 1.11?
Redes
Vamos começar com as redes, desde que o anúncio do Kubernetes 1.11 marcou a estabilização oficial
(isto é, a transferência para o status de disponibilidade geral) de duas importantes inovações apresentadas em versões anteriores. O primeiro deles é
o balanceamento de carga de serviços no cluster, com base
no IPVS (IP Virtual Server). Essa
oportunidade veio da
Huawei que na primavera passada apresentou à comunidade os resultados de seu trabalho para melhorar o balanceamento de carga de mais de 50 mil serviços usando IPVS em vez de tabelas de ip. Essa opção
foi explicada de maneira lógica: “Se o iptables for criado para firewalls e for baseado em listas de regras do kernel, o IPVS é projetado para balanceamento de carga e é baseado em tabelas de hash no kernel; além disso, o IPVS suporta algoritmos de balanceamento de carga mais avançados que o iptables, além de vários outros recursos úteis (por exemplo, verificação de status, tentativas etc.) ".
Deslize do Scaling Kubernetes da Huawei para suportar a apresentação de 50.000 serviços no KubeCon Europe 2017O que isso trouxe na prática? “Melhor largura de banda de rede, menos latência de software
[falando sobre o tempo necessário para novos pontos de extremidade serem adicionados aos serviços - aprox. perev. ] e melhor escalabilidade para o balanceador de carga no cluster ". A versão alfa do modo IPVS para kube-proxy apareceu no
Kubernetes 1.8 e tornou-se estável na versão 1.11 atual: mesmo que por padrão ainda não esteja habilitada, ela já está oficialmente pronta para atender o tráfego em clusters de produção.
O segundo recurso amadurecido é o
CoreDNS como o servidor DNS usado pelo cluster Kubernetes. Escrevemos mais sobre esta solução em uma
revisão separada e, em resumo, é um servidor DNS flexível e facilmente extensível, originalmente baseado no servidor da web
Caddy , que se tornou o sucessor do
SkyDNS (a propósito, o próprio kube-dns se baseia nele, substituído pelo CoreDNS) , escrito em Go e focado no mundo dos aplicativos em nuvem (nativos da nuvem). Outro CoreDNS digno de nota é o fato de que parece ser o único arquivo executável e o único processo no sistema. Agora, essa não é apenas outra opção DNS para o cluster Kubernetes, mas também a opção padrão para o
kubeadm . Instruções para usar o CoreDNS no Kubernetes estão disponíveis
aqui (e para a Cluster Federation,
aqui ).
Entre outras atualizações no "mundo" da rede Kubernetes:
- em NetworkPolicies, agora é possível especificar subaspas específicas em outros namespaces usando
namespaceSelector e podSelector ; - os serviços agora podem escutar nas mesmas portas do host em diferentes interfaces (especificadas em
--nodeport-addresses ); - Foi corrigido um erro devido ao qual o Kubelet ao usar
--node-ip parava de reportar ExternalDNS , InternalDNS e ExternalIP .
Instalações de armazenamento
Introduzido no
Kubernetes 1.9, o recurso de proteção contra remoção de PVCs (
PersistentVolumeClaims ) usado por quaisquer pods e PVs (
PersistentVolumes ) vinculados a PVCs, posteriormente
(no K8s 1.10) chamado
StorageProtection , é declarado estável.
A capacidade de redimensionar o volume (PVs) após reiniciar a lareira foi traduzida para o status beta e, na versão alfa, o
redimensionamento do volume em tempo real tornou-se disponível, ou seja, sem a necessidade de reiniciar a lareira.
Em suporte ao AWS EBS e GCE PD, o limite para o número máximo possível de volumes conectados ao host foi aumentado e nos plug-ins AWS EBS, Azure Disk, GCE PD e Ceph RBD
implementaram suporte para volumes de provisionamento dinâmico de dispositivos brutos de bloco. Para volumes do AWS EBS
, a capacidade de usar pods no modo
ReadOnly também foi
adicionada .
Além disso, o Kubernetes 1.11 introduziu uma versão alfa do
suporte a limites dinâmicos de volumes, dependendo do tipo de nó, bem como o suporte da API para volumes de blocos em drivers de armazenamento externo CSI (
Interface de armazenamento de contêiner - apareceu no
Kubernetes 1.9 ). Além disso, a CSI
implementou a integração com o novo
mecanismo de registro de plugins
Kubelet .
Nós de cluster
As 5 principais mudanças importantes na versão Kubernetes 1.11 também incluem a
transição para o status de uma versão beta da configuração dinâmica do Kubelet , que apareceu pela primeira vez no
K8s 1.8 e requer várias alterações (você pode rastreá-las no
tíquete de configuração original do Dynamic Kubelet ). Esse recurso permite implantar novas configurações do
Kubelet em clusters
ativos e ativos (ao contrário da situação anterior, quando as configurações do
Kubelet eram passadas por sinalizadores da linha de comando). Para usá-lo, você deve definir a opção
--dynamic-config-dir (quando o
Kubelet for iniciado).
O projeto
cri-tools foi declarado estável. Ele oferece ferramentas para administradores de sistema que permitem analisar e depurar a operação de nós na produção, independentemente do tempo de execução do contêiner usado. Pacotes com ele (
crictl ) agora são
enviados com o restante dos utilitários do
kubeadm (nos formatos DEB e RPM).
crictl mais sobre o objetivo e os recursos do crictl em um artigo recente sobre a integração do container com o Kubernetes, substituindo o Docker "tradicional".
Exemplos de uso de crictl da documentação do projetoO
suporte experimental
para sysctls no Linux
foi convertido para o status beta (ativado por padrão usando o
Sysctls recurso
Sysctls ).
PodSecurityPolicy objetos
PodSecurityPolicy e
Pod possuem campos especiais para especificar / controlar
sysctls .
Também no
ResourceQuota foi possível especificar uma classe de prioridade (nesse caso, a cota se aplica apenas aos pods com essa classe - consulte
as propostas de design para obter detalhes) e a condição
ContainersReady foi
adicionada ao status do pod.
Direitos e Segurança
O recurso
ClusterRole Aggregation , apresentado no K8s 1.9, que permite adicionar
permissões a funções existentes (incluindo criadas automaticamente), é declarado estável sem receber alterações. Uma função separada para o cluster-autoscaler (
ClusterRole ) também
foi adicionada - ela é usada em vez do sistema (
cluster-admin ).
Vários trabalhos foram realizados no sentido da transparência do que (e por que) está acontecendo dentro do cluster. Em particular, as informações do RBAC nos logs de auditoria agora
contêm anotações adicionais para eventos :
authorization.k8s.io/decision / authorization.k8s.io/decision - allow ou forbid ;authorization.k8s.io/reason /reason - razão legível para humanos da decisão.
Também nos logs de auditoria, foram
adicionadas informações sobre o acesso do
PodSecurityPolicy na forma de anotações
podsecuritypolicy.admission.k8s.io/admit-policy e
podsecuritypolicy.admission.k8s.io/validate-policy (qual política é permitida em?).
Utilitários de console
Muitas melhorias (embora não tão significativas, mas úteis!) São apresentadas nas ferramentas da CLI do Kubernetes:
- Novo comando
kubectl wait o momento em que os recursos especificados são excluídos ou uma determinada condição é atingida. - Novo
kubectl api-resources para visualizar recursos:
- Suporte de conclusão automática para
kubectl cp . - A função base64decode tornou-se disponível nos modelos do
base64decode Go, cujo nome fala por si. - Adicionado suporte para o
--dry-run no kubectl patch . - O sinalizador
--match-server-version tornou global - a kubectl version do kubectl version também levará isso em consideração. - A
kubectl config view --minify agora leva em consideração o sinalizador de context global. kubectl apply --prune recurso kubectl apply --prune adicionado ao kubectl apply --prune CronJob .
Outras mudanças
- O planejador ( kube-scheduler ) aprendeu a planejar pods no
DaemonSet (versão alfa). - É possível especificar um grupo de usuários do sistema específico (
RunAsGroup ) para contêineres na lareira (versão alfa). - Capacidade de remover órfãos ( exclusão órfã ) de
CustomResources . - Aprimoramentos no suporte da API Kubernetes para lareiras e contêineres no Windows - métricas adicionadas para lareiras, contêineres e um sistema de arquivos com logs, contextos de
run_as_user , volumes constantes locais e fstype para uma unidade do Azure. - O Azure adiciona suporte para o balanceador de carga SKU padrão e IP público.
Compatibilidade
- A versão suportada do etcd é 3.2.18 (o Kubernetes 1.10 era 3.1.12).
- Versões verificadas do Docker - de 1.11.2 a 1.13.1 e 17.03.x (não foram alteradas desde o lançamento do K8s 1.10).
- A versão Go é 1.10.2 (em vez de 1.9.3), o mínimo suportado é 1.9.1.
- A versão CNI é 0.6.0.
- A versão CSI é 0.3.0 (em vez de 0.2.0).
PS
Leia também em nosso blog: