Kubernetes - Kubernetes

Kubernetes
Logotipo do Kubernetes sem workmark.svg
Autor (es) original (is) Google
Desenvolvedor (s) Cloud Native Computing Foundation
lançamento inicial 7 de junho de 2014 ; 7 anos atrás ( 07/06/2014 )
Versão estável
1.22.2 / 4 de agosto de 2021 ; 2 meses atrás ( 2021-08-04 )
Repositório
Escrito em Ir
Modelo Software de gerenciamento de cluster
Licença Licença Apache 2.0
Local na rede Internet kubernetes .io

Kubernetes ( / ˌ k ( j ) u b ər n ɛ t ɪ s , - n t ɪ s , - n t i z / , comumente estilizado como K8s ) é um código-fonte aberto recipiente - orquestração sistema para automatizando a implantação, dimensionamento e gerenciamento de aplicativos de computador . Ele foi originalmente projetado pelo Google e agora é mantido pela Cloud Native Computing Foundation . Seu objetivo é fornecer uma "plataforma para automatizar a implantação, escalonamento e operações de sistemas de gerenciamento de banco de dados". Ele funciona com uma variedade de ferramentas de contêiner e executa contêineres em um cluster, geralmente com imagens criadas usando Docker . O Kubernetes fazia interface originalmente com o tempo de execução do Docker por meio de um "Dockershim"; no entanto, o shim foi suspenso em favor da interface direta com o contêiner por meio do containerd ou da substituição do Docker por um tempo de execução compatível com a Container Runtime Interface (CRI) introduzida pelo Kubernetes em 2016.

Muitos serviços em nuvem oferecem uma plataforma baseada em Kubernetes ou infraestrutura como serviço ( PaaS ou IaaS ) na qual o Kubernetes pode ser implantado como um serviço de fornecimento de plataforma. Muitos fornecedores também oferecem suas próprias distribuições do Kubernetes.

História

Palestra do Google Kubernetes Engine no Google Cloud Summit

Kubernetes ( κυβερνήτης , grego para " timoneiro " ou "piloto" ou "governador" e a raiz etimológica da cibernética ) foi fundado por Ville Aikas, Joe Beda, Brendan Burns e Craig McLuckie, que rapidamente se juntaram a outros engenheiros do Google, incluindo Brian Grant e Tim Hockin, e foi anunciado pela primeira vez pelo Google em meados de 2014. Seu desenvolvimento e design são fortemente influenciados pelo sistema Borg do Google , e muitos dos principais colaboradores do projeto trabalharam anteriormente no Borg. O codinome original para Kubernetes no Google era Projeto 7, uma referência ao personagem Sete dos Nove, ex- Borg de Star Trek . Os sete raios na roda do logotipo do Kubernetes são uma referência a esse codinome. O projeto Borg original foi escrito inteiramente em C ++, mas o sistema Kubernetes reescrito foi implementado em Go .

O Kubernetes v1.0 foi lançado em 21 de julho de 2015. Junto com o lançamento do Kubernetes v1.0, o Google fez uma parceria com a Linux Foundation para formar a Cloud Native Computing Foundation (CNCF) e ofereceu o Kubernetes como uma tecnologia inicial. Em fevereiro de 2016, o gerenciador de pacotes Helm para Kubernetes foi lançado. Em 6 de março de 2018, o Projeto Kubernetes alcançou o nono lugar em commits no GitHub e o segundo lugar em autores e edições, depois do kernel Linux .

Até a v1.18, o Kubernetes seguia uma política de suporte N-2 (o que significa que as três versões secundárias mais recentes recebem segurança e correções de bugs).

Da v1.19 em diante, o Kubernetes seguirá uma política de suporte N-3.

Histórico de lançamento
Versão Data de lançamento Data de término do suporte Notas
Versão antiga, não mais mantida: 1.0 10 de julho de 2015 Lançamento Original
Versão antiga, não mais mantida: 1,1 9 de novembro de 2015 https://kubernetes.io/blog/2015/11/kubernetes-1-1-performance-upgrades-improved-tooling-and-a-growing-community
Versão antiga, não mais mantida: 1,2 16 de março de 2016 23 de outubro de 2016 https://kubernetes.io/blog/2016/03/kubernetes-1-2-even-more-performance-upgrades-plus-easier-application-deployment-and-management
Versão antiga, não mais mantida: 1,3 1 de julho de 2016 1 de novembro de 2016 https://kubernetes.io/blog/2016/07/kubernetes-1-3-bridging-cloud-native-and-enterprise-workloads
Versão antiga, não mais mantida: 1,4 26 de setembro de 2016 21 de abril de 2017 https://kubernetes.io/blog/2016/09/kubernetes-1-4-making-it-easy-to-run-on-kuberentes-anywhere
Versão antiga, não mais mantida: 1,5 12 de dezembro de 2016 1 de outubro de 2017 https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads
Versão antiga, não mais mantida: 1,6 28 de março de 2017 23 de novembro de 2017 https://kubernetes.io/blog/2017/03/kubernetes-1-6-multi-user-multi-workloads-at-scale
Versão antiga, não mais mantida: 1,7 30 de junho de 2017 4 de abril de 2018 https://kubernetes.io/blog/2017/06/kubernetes-1-7-security-hardening-stateful-application-extensibility-updates
Versão antiga, não mais mantida: 1.8 28 de agosto de 2017 12 de julho de 2018 https://kubernetes.io/blog/2017/09/kubernetes-18-security-workloads-and
Versão antiga, não mais mantida: 1,9 15 de dezembro de 2017 29 de setembro de 2018 https://kubernetes.io/blog/2017/12/kubernetes-19-workloads-expanded-ecosystem
Versão antiga, não mais mantida: 1,10 28 de março de 2018 13 de fevereiro de 2019 https://kubernetes.io/blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking
Versão antiga, não mais mantida: 1,11 3 de julho de 2018 1 de maio de 2019 https://kubernetes.io/blog/2018/06/27/kubernetes-1.11-release-announcement
Versão antiga, não mais mantida: 1,12 27 de setembro de 2018 8 de julho de 2019 https://kubernetes.io/blog/2018/09/27/kubernetes-1.12-kubelet-tls-bootstrap-and-azure-virtual-machine-scale-sets-vmss-move-to-general-availability
Versão antiga, não mais mantida: 1,13 3 de dezembro de 2018 15 de outubro de 2019 https://kubernetes.io/blog/2018/12/03/kubernetes-1-13-release-announcement
Versão antiga, não mais mantida: 1,14 25 de março de 2019 11 de dezembro de 2019 https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-announcement
Versão antiga, não mais mantida: 1,15 20 de junho de 2019 6 de maio de 2020 https://kubernetes.io/blog/2019/06/19/kubernetes-1-15-release-announcement
Versão antiga, não mais mantida: 1,16 22 de outubro de 2019 2 de setembro de 2020 https://kubernetes.io/blog/2019/09/18/kubernetes-1-16-release-announcement
Versão antiga, não mais mantida: 1,17 9 de dezembro de 2019 30 de janeiro de 2021 https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement
Versão antiga, não mais mantida: 1,18 25 de março de 2020 30 de abril de 2021 https://kubernetes.io/blog/2020/03/25/kubernetes-1-18-release-announcement
Versão mais antiga, mas ainda mantida: 1,19 26 de agosto de 2020 30 de setembro de 2021 A partir do Kubernetes versão 1.19, a janela de suporte será estendida para um ano https://kubernetes.io/blog/2020/08/26/kubernetes-release-1.19-accentuate-the-paw-sitive
Versão mais antiga, mas ainda mantida: 1,20 8 de dezembro de 2020 30 de dezembro de 2021 https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/
Versão mais antiga, mas ainda mantida: 1,21 8 de abril de 2021 30 de abril de 2022 https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/
Versão estável atual: 1,22 4 de agosto de 2021 4 de agosto de 2022 https://kubernetes.io/blog/2021/08/04/kubernetes-1-22-release-announcement/
Versão futura: 1,23 7 de dezembro de 2021 7 de dezembro de 2022 https://www.kubernetes.dev/resources/release/
Lenda:
Versão antiga
Versão mais antiga, ainda mantida
Última versão
Versão de visualização mais recente
Lançamento futuro

Janelas de suporte

O gráfico abaixo mostra o período para o qual cada versão é / foi suportada

Conceitos

Diagrama da arquitetura Kubernetes

O Kubernetes define um conjunto de blocos de construção ("primitivos"), que fornecem coletivamente mecanismos que implantam, mantêm e dimensionam aplicativos com base na CPU, memória ou métricas personalizadas. O Kubernetes é fracamente acoplado e extensível para atender a diferentes cargas de trabalho. Essa extensibilidade é fornecida em grande parte pela API Kubernetes, que é usada por componentes internos, bem como extensões e contêineres executados no Kubernetes. A plataforma exerce seu controle sobre os recursos de computação e armazenamento definindo recursos como Objetos, que podem então ser gerenciados como tal.

O Kubernetes segue a arquitetura primária / réplica . Os componentes do Kubernetes podem ser divididos entre aqueles que gerenciam um individual e aqueles que fazem parte do plano de controle.

Objetos de Cluster

Avião de controle

O mestre do Kubernetes é a principal unidade de controle do cluster, gerenciando sua carga de trabalho e direcionando a comunicação em todo o sistema. O plano de controle do Kubernetes consiste em vários componentes, cada um com seu próprio processo, que podem ser executados em um único nó mestre ou em vários mestres com suporte a clusters de alta disponibilidade . Os vários componentes do plano de controle do Kubernetes são os seguintes:

  • etcd: etcd é um armazenamento de dados de valor-chave persistente, leve, distribuído desenvolvido pela CoreOS que armazena de forma confiável os dados de configuração do cluster, representando o estado geral do cluster em qualquer ponto do tempo. Assim como o Apache ZooKeeper , o etcd é um sistema que favorece a consistência em vez da disponibilidade no caso de uma partição de rede (consulte o teorema CAP ). Essa consistência é crucial para agendar e operar serviços corretamente. O servidor da API Kubernetes usa a API watch do etcd para monitorar o cluster e implementar mudanças críticas de configuração ou simplesmente restaurar quaisquer divergências do estado do cluster de volta ao que foi declarado pelo implantador. Por exemplo, se o implantador especificou que três instâncias de um pod específico precisam estar em execução, esse fato será armazenado no etcd. Se for constatado que apenas duas instâncias estão em execução, esse delta será detectado em comparação com os dados etcd, e o Kubernetes usará isso para agendar a criação de uma instância adicional desse pod.
  • Servidor de API: o servidor de API é um componente-chave e serve a API Kubernetes usando JSON sobre HTTP , que fornece a interface interna e externa para o Kubernetes. O servidor API processa e valida solicitações REST e atualiza o estado dos objetos API no etcd, permitindo que os clientes configurem cargas de trabalho e contêineres em nós de trabalho.
  • Agendador: o agendador é o componente conectável que seleciona em qual nó um pod não agendado (a entidade básica gerenciada pelo agendador) é executado, com base na disponibilidade de recursos. O planejador rastreia o uso de recursos em cada nó para garantir que a carga de trabalho não seja planejada além dos recursos disponíveis. Para este propósito, o planejador deve conhecer os requisitos de recursos, disponibilidade de recursos e outras restrições fornecidas pelo usuário e diretivas de política, como qualidade de serviço, requisitos de afinidade / antiafinidade, localidade de dados e assim por diante. Em essência, a função do planejador é combinar o "suprimento" de recursos com a "demanda" da carga de trabalho.
  • Gerenciador de controlador: um controlador é um loop de reconciliação que direciona o estado real do cluster em direção ao estado do cluster desejado, comunicando-se com o servidor API para criar, atualizar e excluir os recursos que ele gerencia (pods, terminais de serviço, etc.). O gerenciador de controlador é um processo que gerencia um conjunto de controladores Kubernetes principais. Um tipo de controlador é o Controlador de replicação, que lida com a replicação e o dimensionamento executando um número especificado de cópias de um pod em todo o cluster. Ele também lida com a criação de pods de substituição se o nó subjacente falhar. Outros controladores que fazem parte do sistema Kubernetes principal incluem um DaemonSet Controller para executar exatamente um pod em cada máquina (ou algum subconjunto de máquinas) e um Job Controller para executar pods que são executados até a conclusão, por exemplo, como parte de um trabalho em lote. O conjunto de pods que um controlador gerencia é determinado por seletores de rótulo que fazem parte da definição do controlador.

Nós

Um Node, também conhecido como Worker ou Minion, é uma máquina onde os contêineres (cargas de trabalho) são implantados. Cada nó no cluster deve executar um tempo de execução de contêiner , como Docker , bem como os componentes mencionados abaixo, para comunicação com o primário para configuração de rede desses contêineres.

  • Kubelet: Kubelet é responsável pelo estado de execução de cada nó, garantindo que todos os contêineres no nó estejam íntegros. Ele se encarrega de iniciar, parar e manter os contêineres de aplicativos organizados em pods, conforme direcionado pelo plano de controle.
O Kubelet monitora o estado de um pod e, se não estiver no estado desejado, o pod é reimplantado no mesmo nó. O status do nó é retransmitido a cada poucos segundos por meio de mensagens de pulsação para o primário. Depois que o primário detecta uma falha de nó, o Controlador de replicação observa essa mudança de estado e inicia pods em outros nós íntegros.
  • Kube-proxy: o Kube-proxy é uma implementação de um proxy de rede e um balanceador de carga e oferece suporte à abstração de serviço junto com outras operações de rede. Ele é responsável por rotear o tráfego para o contêiner apropriado com base no IP e no número da porta da solicitação de entrada.
  • Tempo de execução do contêiner: um contêiner reside dentro de um pod. O contêiner é o nível mais baixo de um microsserviço, que contém o aplicativo em execução, as bibliotecas e suas dependências. Os contêineres podem ser expostos ao mundo por meio de um endereço IP externo. O Kubernetes oferece suporte a contêineres Docker desde sua primeira versão e, em julho de 2016, o mecanismo de contêiner rkt foi adicionado.

Namespaces

O Kubernetes fornece um particionamento dos recursos que gerencia em conjuntos não sobrepostos chamados namespaces. Eles se destinam ao uso em ambientes com muitos usuários espalhados por várias equipes ou projetos, ou até mesmo ambientes separados como desenvolvimento, teste e produção.

DaemonSets

Normalmente, os locais onde os pods são executados são determinados pelo algoritmo implementado no Agendador do Kubernetes. Para alguns casos de uso, porém, pode ser necessário executar um pod em cada nó do cluster. Isso é útil para casos de uso como coleta de log, controladores de ingresso e serviços de armazenamento. A capacidade de fazer esse tipo de programação de pod é implementada pelo recurso chamado DaemonSets.

Objetos de carga de trabalho

Pods

A unidade de programação básica no Kubernetes é um pod . Um pod é um agrupamento de componentes em contêineres. Um pod consiste em um ou mais contêineres com garantia de localização no mesmo nó.

Cada pod no Kubernetes recebe um endereço IP exclusivo dentro do cluster, o que permite que os aplicativos usem portas sem o risco de conflito. Dentro do pod, todos os contêineres podem fazer referência uns aos outros no localhost, mas um contêiner em um pod não tem como abordar diretamente outro contêiner em outro pod. para isso, tem que usar o endereço IP do pod. No entanto, um desenvolvedor de aplicativo nunca deve usar o endereço IP do pod para fazer referência / invocar um recurso em outro pod, pois os endereços IP do pod são efêmeros - o pod específico ao qual estão se referindo pode ser atribuído a outro endereço IP do pod na reinicialização. Em vez disso, eles devem usar uma referência a um serviço , que contém uma referência ao pod de destino no endereço IP do pod específico.

Um pod pode definir um volume, como um diretório de disco local ou um disco de rede, e expô-lo aos contêineres do pod. Os pods podem ser gerenciados manualmente por meio da API Kubernetes ou seu gerenciamento pode ser delegado a um controlador. Esses volumes também são a base para os recursos do Kubernetes de ConfigMaps (para fornecer acesso à configuração por meio do sistema de arquivos visível para o contêiner) e Secrets (para fornecer acesso às credenciais necessárias para acessar recursos remotos com segurança, fornecendo essas credenciais no sistema de arquivos visíveis apenas para recipientes autorizados).

ReplicaSets

O objetivo de um ReplicaSet é manter um conjunto estável de pods de réplica em execução a qualquer momento. Como tal, costuma ser usado para garantir a disponibilidade de um número especificado de pods idênticos.

Os ReplicaSets também podem ser considerados um mecanismo de agrupamento que permite ao Kubernetes manter o número de instâncias declaradas para um determinado pod. A definição de um conjunto de réplicas usa um seletor, cuja avaliação resultará na identificação de todos os pods associados a ele.

Serviços

Visualização simplificada que mostra como os serviços interagem com a rede de pods em um cluster Kubernetes

Um serviço Kubernetes é um conjunto de pods que funcionam juntos, como uma camada de um aplicativo multicamadas . O conjunto de pods que constituem um serviço é definido por um seletor de rótulos. O Kubernetes oferece dois modos de descoberta de serviço , usando variáveis ​​ambientais ou DNS do Kubernetes. A descoberta de serviço atribui um endereço IP estável e um nome DNS ao serviço e equilibra a carga do tráfego em rodízio para conexões de rede desse endereço IP entre os pods que correspondem ao seletor (mesmo que as falhas façam com que os pods se movam de máquina para máquina ) Por padrão, um serviço é exposto dentro de um cluster (por exemplo, pods de back-end podem ser agrupados em um serviço, com solicitações dos pods de front-end com balanceamento de carga entre eles), mas um serviço também pode ser exposto fora de um cluster (por exemplo, para que os clientes alcancem pods de front-end).

Volumes

Os sistemas de arquivos no contêiner Kubernetes fornecem armazenamento efêmero , por padrão. Isso significa que a reinicialização do pod apagará todos os dados desses contêineres e, portanto, essa forma de armazenamento é bastante limitante em qualquer coisa, exceto em aplicativos triviais. Um volume do Kubernetes fornece armazenamento persistente que existe durante a vida útil do próprio pod. Esse armazenamento também pode ser usado como espaço em disco compartilhado para contêineres dentro do pod. Os volumes são montados em pontos de montagem específicos dentro do contêiner, que são definidos pela configuração do pod, e não podem ser montados em outros volumes ou vinculados a outros volumes. O mesmo volume pode ser montado em diferentes pontos da árvore do sistema de arquivos por diferentes contêineres.

ConfigMaps e segredos

Um desafio comum do aplicativo é decidir onde armazenar e gerenciar as informações de configuração, algumas das quais podem conter dados confidenciais. Os dados de configuração podem ser tão refinados como propriedades individuais ou informações grosseiras, como arquivos de configuração inteiros ou documentos JSON / XML. O Kubernetes fornece dois mecanismos intimamente relacionados para lidar com essa necessidade: "configmaps" e "secrets", os quais permitem que alterações de configuração sejam feitas sem a necessidade de compilar um aplicativo. Os dados de configmaps e segredos serão disponibilizados para cada instância do aplicativo ao qual esses objetos foram vinculados por meio da implantação. Um segredo e / ou um configmap só é enviado a um nó se um pod nesse nó exigir. O Kubernetes o manterá na memória desse nó. Depois que o pod que depende do segredo ou do configmap é excluído, a cópia na memória de todos os segredos e configmaps vinculados também é excluída. Os dados podem ser acessados ​​no pod de duas maneiras: a) como variáveis ​​de ambiente (que serão criadas pelo Kubernetes quando o pod for iniciado) ou b) disponíveis no sistema de arquivos do contêiner que é visível apenas de dentro do pod.

Os dados em si são armazenados no mestre, que é uma máquina altamente segura à qual ninguém deve ter acesso de login. A maior diferença entre um segredo e um configmap é que o conteúdo dos dados em um segredo é codificado em base64. Versões recentes do Kubernetes introduziram suporte para criptografia a ser usada também. Os segredos são freqüentemente usados ​​para armazenar dados como certificados, senhas, puxar segredos (credenciais para trabalhar com registros de imagem) e chaves ssh.

StatefulSets

É muito fácil lidar com o dimensionamento de aplicativos sem estado: basta adicionar mais pods em execução - algo que o Kubernetes faz muito bem. Cargas de trabalho com estado são muito mais difíceis, porque o estado precisa ser preservado se um pod for reiniciado e se o aplicativo for ampliado ou reduzido, o estado pode precisar ser redistribuído. Os bancos de dados são um exemplo de cargas de trabalho com estado. Quando executados no modo de alta disponibilidade, muitos bancos de dados vêm com a noção de uma instância primária e instância (s) secundária (s). Nesse caso, a noção de ordenação das instâncias é importante. Outros aplicativos, como o Kafka, distribuem os dados entre seus corretores - portanto, um corretor não é igual ao outro. Nesse caso, a noção de exclusividade da instância é importante. StatefulSets são controladores (consulte Controller Manager , acima) fornecidos pelo Kubernetes que impõem as propriedades de exclusividade e ordenação entre as instâncias de um pod e podem ser usados ​​para executar aplicativos com estado.

Controladores de replicação e implantações

Um ReplicaSet declara o número de instâncias de um pod necessário e um Controlador de replicação gerencia o sistema para que o número de pods íntegros em execução corresponda ao número de pods declarado no ReplicaSet (determinado pela avaliação de seu seletor).

As implantações são um mecanismo de gerenciamento de nível superior para ReplicaSets. Enquanto o Replication Controller gerencia a escala do ReplicaSet, as implantações gerenciam o que acontece com o ReplicaSet - se uma atualização deve ser lançada ou revertida, etc. Quando as implantações são ampliadas ou reduzidas, isso resulta na declaração do Mudança de ReplicaSet - e essa mudança no estado declarado é gerenciada pelo Replication Controller.

Rótulos e seletores

O Kubernetes permite que clientes (usuários ou componentes internos) anexem chaves chamadas "rótulos" a qualquer objeto de API no sistema, como pods e nós . Da mesma forma, "seletores de rótulo" são consultas em rótulos que resolvem para objetos correspondentes. Quando um serviço é definido, é possível definir os seletores de rótulo que serão usados ​​pelo roteador de serviço / balanceador de carga para selecionar as instâncias de pod para as quais o tráfego será roteado. Assim, simplesmente alterar os rótulos dos pods ou alterar os seletores de rótulo no serviço pode ser usado para controlar quais pods recebem tráfego e quais não, o que pode ser usado para oferecer suporte a vários padrões de implantação, como implantações azul-verde ou teste AB . Essa capacidade de controlar dinamicamente como os serviços utilizam recursos de implementação fornece um acoplamento fraco dentro da infraestrutura.

Por exemplo, se vagens de um aplicativo têm rótulos para um sistema tier(com valores como front-end, back-endpor exemplo) e um release_track(com valores como canary, productionpor exemplo), em seguida, uma operação em todos back-ende canarynós pode usar um seletor de rótulo, tais Como:

tier=back-end AND release_track=canary

Assim como os rótulos, os seletores de campo também permitem selecionar recursos do Kubernetes. Ao contrário dos rótulos, a seleção é baseada nos valores de atributo inerentes ao recurso que está sendo selecionado, ao invés da categorização definida pelo usuário. metadata.namee metadata.namespacesão seletores de campo que estarão presentes em todos os objetos Kubernetes. Outros seletores que podem ser usados ​​dependem do tipo de objeto / recurso.

Complementos

Os complementos operam como qualquer outro aplicativo em execução no cluster: eles são implementados por meio de pods e serviços e são diferentes apenas porque implementam recursos do cluster Kubernetes. Os pods podem ser gerenciados por implantações, ReplicationControllers e assim por diante. Existem muitos complementos e a lista está crescendo. Alguns dos mais importantes são:

  • DNS: todos os clusters Kubernetes devem ter DNS de cluster; é um recurso obrigatório. O DNS de cluster é um servidor DNS, além dos outros servidores DNS em seu ambiente, que fornece registros DNS para serviços do Kubernetes. Os contêineres iniciados pelo Kubernetes incluem automaticamente esse servidor DNS em suas pesquisas DNS.
  • IU da Web: é uma IU de uso geral baseada na Web para clusters do Kubernetes. Ele permite que os usuários gerenciem e solucionem problemas de aplicativos em execução no cluster, bem como no próprio cluster.
  • Monitoramento de recursos de contêiner: fornecer um tempo de execução de aplicativo confiável e ser capaz de aumentá-lo ou diminuí-lo em resposta às cargas de trabalho significa ser capaz de monitorar de forma contínua e eficaz o desempenho da carga de trabalho. O Container Resource Monitoring fornece esse recurso registrando métricas sobre os containers em um banco de dados central e fornece uma IU para navegar pelos dados. O cAdvisor é um componente em um nó escravo que fornece um recurso de monitoramento métrico limitado. Também há pipelines completos de métricas, como o Prometheus, que pode atender à maioria das necessidades de monitoramento.
  • Registro em nível de cluster: os registros devem ter armazenamento e ciclo de vida separados, independente de nós, pods ou contêineres. Caso contrário, as falhas do nó ou pod podem causar perda de dados do evento. A capacidade de fazer isso é chamada de log em nível de cluster, e tais mecanismos são responsáveis ​​por salvar logs de contêiner em um armazenamento de log central com interface de pesquisa / navegação. O Kubernetes não fornece armazenamento nativo para dados de registro, mas pode-se integrar muitas soluções de registro existentes ao cluster do Kubernetes.

Armazenar

Os contêineres surgiram como uma forma de tornar o software portátil. O contêiner contém todos os pacotes de que você precisa para executar um serviço. O sistema de arquivos fornecido torna os contêineres extremamente portáteis e fáceis de usar no desenvolvimento. Um contêiner pode ser movido do desenvolvimento para o teste ou produção com nenhuma ou relativamente poucas alterações de configuração.

Historicamente, o Kubernetes era adequado apenas para serviços sem estado. No entanto, muitos aplicativos têm um banco de dados, que requer persistência, o que leva à criação de armazenamento persistente para Kubernetes. Implementar armazenamento persistente para contêineres é um dos principais desafios dos administradores do Kubernetes, DevOps e engenheiros de nuvem. Os contêineres podem ser efêmeros, mas cada vez mais seus dados não são, portanto, é necessário garantir a sobrevivência dos dados em caso de encerramento do contêiner ou falha de hardware. Ao implantar contêineres com Kubernetes ou aplicativos em contêineres, as empresas geralmente percebem que precisam de armazenamento persistente. Eles precisam fornecer armazenamento rápido e confiável para bancos de dados, imagens raiz e outros dados usados ​​pelos contêineres.

Além da paisagem, a Cloud Native Computing Foundation (CNCF) publicou outras informações sobre o armazenamento persistente do Kubernetes, incluindo um blog que ajuda a definir o padrão de armazenamento anexado ao contêiner. Esse padrão pode ser considerado como aquele que usa o próprio Kubernetes como um componente do sistema ou serviço de armazenamento.

Mais informações sobre a popularidade relativa dessas e de outras abordagens também podem ser encontradas no levantamento paisagístico do CNCF, que mostrou que OpenEBS de MayaData e Rook - um projeto de orquestração de armazenamento - eram os dois projetos com maior probabilidade de estar em avaliação no outono de 2019.

O Container Attached Storage é um tipo de armazenamento de dados que surgiu conforme o Kubernetes ganhou destaque. A abordagem ou padrão do Container Attached Storage depende do próprio Kubernetes para determinados recursos, ao mesmo tempo que fornece blocos, arquivos, objetos e interfaces principalmente para cargas de trabalho em execução no Kubernetes.

Os atributos comuns do Container Attached Storage incluem o uso de extensões para Kubernetes, como definições de recursos personalizadas, e o uso do próprio Kubernetes para funções que, de outra forma, seriam desenvolvidas e implantadas separadamente para armazenamento ou gerenciamento de dados. Exemplos de funcionalidade fornecida por definições de recursos personalizadas ou pelo próprio Kubernetes incluem lógica de repetição, fornecida pelo próprio Kubernetes, e a criação e manutenção de um inventário de mídias e volumes de armazenamento disponíveis, normalmente entregue por meio de uma definição de recurso personalizada.

API

Um componente-chave do plano de controle do Kubernetes é o servidor de API, que expõe uma API HTTP que pode ser chamada por outras partes do cluster, bem como por usuários finais e componentes externos. Esta API é uma API REST e é de natureza declarativa. Existem dois tipos de recursos de API. A maioria dos recursos da API na API Kubernetes são objetos. Eles representam uma instância concreta de um conceito no cluster, como um pod ou namespace. Um pequeno número de tipos de recursos da API são "virtuais". Eles representam operações em vez de objetos, como uma verificação de permissão, usando o recurso "subjectaccessreviews". Os recursos da API que correspondem aos objetos serão representados no cluster com identificadores exclusivos para os objetos. Os recursos virtuais não têm identificadores exclusivos.

Operadores

O Kubernetes pode ser estendido usando recursos personalizados. Esses recursos da API representam objetos que não fazem parte do produto Kubernetes padrão. Esses recursos podem aparecer e desaparecer em um cluster em execução por meio do registro dinâmico. Os administradores de cluster podem atualizar recursos personalizados independentemente do cluster.

Os controladores personalizados são outro mecanismo de extensão. Eles interagem com os recursos personalizados e permitem uma API verdadeiramente declarativa que permite o gerenciamento do ciclo de vida do recurso personalizado, alinhado com a forma como o próprio Kubernetes foi projetado. A combinação de recursos personalizados e controladores personalizados é geralmente chamada de operador (Kubernetes). O principal caso de uso para Operadores é capturar o objetivo de um operador humano que está gerenciando um serviço ou conjunto de serviços e implementá-los usando automação, e com uma API declarativa que suporte essa automação. Operadores humanos que cuidam de aplicativos e serviços específicos têm profundo conhecimento de como o sistema deve se comportar, como implantá-lo e como reagir se houver problemas. Exemplos de problemas resolvidos pelos operadores incluem fazer e restaurar backups do estado do aplicativo e lidar com atualizações do código do aplicativo junto com alterações relacionadas, como esquemas de banco de dados ou configurações extras.

API de cluster

Os mesmos princípios de design de API foram usados ​​para definir uma API para criar, configurar e gerenciar clusters Kubernetes de maneira programática. Isso é chamado de API de cluster. Um conceito-chave incorporado à API é a noção de que o cluster do Kubernetes é um recurso / objeto que pode ser gerenciado como qualquer outro recurso do Kubernetes. Da mesma forma, as máquinas que compõem o cluster também são tratadas como um recurso do Kubernetes. A API tem duas partes - a API principal e uma implementação de provedor. A implementação do provedor consiste em funções específicas do provedor de nuvem que permitem que o Kubernetes forneça a API do cluster de uma forma bem integrada com os serviços e recursos do provedor de nuvem.

Usos

O Kubernetes é comumente usado como uma maneira de hospedar uma implementação baseada em microsserviço, porque ele e seu ecossistema de ferramentas associado fornecem todos os recursos necessários para resolver os principais problemas de qualquer arquitetura de microsserviço .

Veja também

Referências

links externos