Conceitos de Container Engine e Kubernetes

Descubra os principais conceitos que você precisa entender antes de usar o Container Engine for Kubernetes (OKE).

Este tópico descreve os principais conceitos que você precisa compreender ao usar o serviço Container Engine for Kubernetes.

Clusters do Kubernetes

Um cluster do Kubernetes é um grupo de nós (máquinas que executam aplicativos). Cada nó pode ser uma máquina física ou uma máquina virtual. A capacidade do nó (seu número de CPUs e quantidade de memória) é definida quando o nó é criado. Um cluster compreende:

Nós do plano de controle (anteriormente referidos como 'nós principais'). Normalmente, haverá três nós de plano de controle para alta disponibilidade.
Nós de trabalho, organizados em pools de nós.

Ao criar um cluster usando o Container Engine for Kubernetes, você pode criar o novo cluster como cluster básico ou como cluster aprimorado.

Clusters Avançados e Básicos

Ao criar um novo cluster com o Container Engine for Kubernetes, você especifica o tipo de cluster a ser criado. Você pode especificar:

Cluster aprimorado: Clusters aprimorados suportam todos os recursos disponíveis, incluindo recursos não suportados por clusters básicos (como nós virtuais, gerenciamento de complementos de cluster, identidade de carga de trabalho e nós de trabalho adicionais por cluster). Os clusters aprimorados vêm com um SLA (Service Level Agreement) apoiado financeiramente.
Cluster básico: Os clusters básicos suportam todas as funcionalidades básicas fornecidas pelo Kubernetes e pelo Container Engine for Kubernetes, mas nenhum dos recursos avançados fornecidos pelo Container Engine for Kubernetes. Os clusters básicos vêm com um objetivo de nível de serviço (SLO), mas não um SLA (Service Level Agreement) apoiado financeiramente.

Observe o seguinte ao criar clusters:

Ao usar a Console para criar um cluster, se você não selecionar nenhum recurso aprimorado durante a criação do cluster, terá a opção de criar o novo cluster como cluster básico. Um novo cluster é criado como um cluster aprimorado por padrão, a menos que você escolha explicitamente criar um cluster básico.
Ao usar a CLI ou a API para criar um cluster, você pode especificar se deseja criar um cluster básico ou um cluster aprimorado. Se você não especificar explicitamente o tipo de cluster a ser criado, um novo cluster será criado como um cluster básico por padrão.

A criação de um novo cluster como um cluster aprimorado permite que você adicione facilmente recursos aprimorados posteriormente, mesmo que não tenha selecionado recursos aprimorados inicialmente. Se optar por criar um novo cluster como cluster básico, você ainda poderá optar por fazer upgrade do cluster básico para um cluster aprimorado posteriormente. No entanto, você não pode fazer downgrade de um cluster aprimorado para um cluster básico.

Consulte Comparando Clusters Aprimorados com Clusters Básicos.

Observe que todas as referências a 'clusters' na documentação do serviço Container Engine for Kubernetes se referem a clusters aprimorados e clusters básicos, a menos que explicitamente declarado de outra forma.

Plano de Controle de Cluster do Kubernetes e API do Kubernetes

O plano de controle de cluster do Kubernetes implementa a funcionalidade central do Kubernetes. Ele é executado em instâncias de computação (conhecidas como 'nós do plano de controle') na tenancy de serviço do Container Engine for Kubernetes. O plano de controle de cluster é totalmente gerenciado pela Oracle.

O plano de controle de cluster executa vários processos, incluindo:

kube-apiserver para suportar operações de API do Kubernetes solicitadas pela ferramenta de linha de comando do Kubernetes (kubectl) e por outras ferramentas de linha de comando, bem como por chamadas REST diretas. O kube-apiserver inclui os controladores de admissões necessários para operações avançadas do Kubernetes.
kube-controller-manager para gerenciar diferentes componentes do Kubernetes (por exemplo, controlador de replicação, controlador de pontos finais, controlador de namespace e controlador de contas de serviço)
kube-scheduler para controlar em que local do cluster os jobs serão executados
etcd para armazenar os dados de configuração do cluster
cloud-controller-manager para atualizar e excluir nós de trabalho (usando o controlador de nó), para criar balanceadores de carga quando serviços do Kubernetes de type: LoadBalancer são criados (usando o controlador de serviço) e para configurar rotas de rede (usando o controlador de rota). O oci-cloud-controller-manager também implementa um contêiner-storage-interface, um driver de flexvolume e um provisionador de flexvolume (para obter mais informações, consulte a documentação do OCI Cloud Controller Manager (CCM) no GitHub).

A API do Kubernetes permite que os usuários finais consultem e manipulem recursos do Kubernetes (como pods, namespaces, mapas de configuração e eventos).

Você acessa a API do Kubernetes no plano de controle de cluster por meio de um ponto final hospedado em uma sub-rede da sua VCN. Esta sub-rede de ponto final da API do Kubernetes pode ser uma sub-rede pública ou privada. Se você especificar uma sub-rede pública para o ponto final da API do Kubernetes, terá a opção de expor o ponto final à internet designando um endereço IP público ao ponto final (e também ao endereço IP privado). Você controla o acesso à sub-rede do ponto final da API do Kubernetes usando regras de segurança definidas para grupos de segurança de rede (recomendado) ou listas de segurança.

Observação

Em versões anteriores, os clusters foram provisionados com pontos finais públicos de API do Kubernetes que não foram integrados à sua VCN.

Você pode continuar a criar esses clusters usando a CLI ou a API, mas não a Console. Observe que você só pode criar esses clusters como clusters básicos, não como aprimorados.

Nós de Trabalho do Kubernetes, Pools de Nós e o Cluster Data Plane

Os nós de trabalho constituem o plano de dados do cluster. Os nós de trabalho são o local onde você executa os aplicativos implantados em um cluster.

Cada nó de trabalho executa vários processos, incluindo:

kubelet para comunicação com o plano de controle de cluster
kube-proxy para manter regras de rede

Os processos do plano de controle de cluster monitoram e registram o estado dos nós de trabalho e distribuem as operações solicitadas entre eles.

Um pool de nós representa um subconjunto de nós de trabalho em um cluster em que todos têm a mesma configuração. Os pools de nós permitem criar pools de máquinas em um cluster que tenham configurações distintas. Por exemplo, você pode criar um pool de nós em um cluster como máquinas virtuais e outro pool de nós como máquinas bare metal. Um cluster deve ter no mínimo um pool de nós, mas um pool de nós não precisa conter nós de trabalho.

Os nós de trabalho em um pool de nós estão conectados a uma sub-rede de nós de trabalho na sua VCN.

Ao criar um pool de nós, você especifica que os nós de trabalho no pool de nós são todos criados como nós virtuais ou todos criados como nós gerenciados.

Nós Virtuais e Nós Gerenciados

Ao criar um pool de nós com o Container Engine for Kubernetes, você especifica que os nós de trabalho no pool de nós devem ser criados como um ou outro dos seguintes:

Nós virtuais, totalmente gerenciados pela Oracle. Os nós virtuais fornecem uma experiência de Kubernetes 'sem servidor', permitindo que você execute aplicativos em contêineres em escala sem a sobrecarga operacional de fazer upgrade da infraestrutura de plano de dados e gerenciar a capacidade dos clusters. Você só pode criar nós virtuais em clusters aprimorados.
Nós gerenciados, executados em instâncias de computação (bare metal ou máquina virtual) em sua locação e pelo menos parcialmente gerenciados por você. Como você é responsável pelo gerenciamento de nós gerenciados, tem a flexibilidade de configurá-los para atender aos seus requisitos específicos. Você é responsável por fazer upgrade do Kubernetes nos nós gerenciados e por gerenciar a capacidade do cluster. Você pode criar nós gerenciados em clusters básicos e avançados.

Consulte Comparando Nós Virtuais com Nós Gerenciados.

Observe que todas as referências a 'nós' e 'nós de trabalho' na documentação do serviço Container Engine for Kubernetes se referem a nós virtuais e nós gerenciados, a menos que explicitamente declarado de outra forma.

Nós Autogerenciados

Um nó autogerenciado é um nó de trabalho hospedado em uma instância de computação (ou pool de instâncias) que você mesmo criou no serviço Compute, em vez de em uma instância de computação que o Container Engine for Kubernetes criou para você. Os nós autogerenciados geralmente são chamados de BYON (Bring Your Own Nodes). Diferentemente dos nós gerenciados e dos nós virtuais (que são agrupados em pools de nós gerenciados e pools de nós virtuais, respectivamente), os nós autogerenciados não são agrupados em pools de nós.

Você usa o serviço Compute para criar as instâncias de computação nas quais hospedar nós autogerenciados. O uso do serviço Compute permite configurar instâncias de computação para cargas de trabalho especializadas, incluindo combinações de forma de computação e imagem que não estão disponíveis para nós gerenciados e nós virtuais. Por exemplo, talvez você queira instâncias com formas projetadas para cargas de trabalho aceleradas por hardware (como formas de GPU) ou formas projetadas para cargas de trabalho de computação de alto desempenho (HPC) que exijam núcleos de processador de alta frequência (como formas HPC e Otimizadas). Talvez você queira conectar muitas dessas instâncias com uma rede de alta largura de banda e ultra baixa latência para formar uma rede de clusters do Oracle Cloud Infrastructure (consulte Usando Redes de Clusters RDMA).

Se você quiser simplificar a administração e gerenciar vários nós autogerenciados como um grupo, use o serviço Compute para criar um pool de instâncias de computação para hospedar um ou mais nós autogerenciados.

Ao criar uma instância de computação (ou um pool de instâncias) para hospedar um nó autogerenciado, você especifica o cluster do Kubernetes ao qual adicionar a instância. Você só pode adicionar nós autogerenciados a clusters aprimorados.

Para obter mais informações, consulte Trabalhando com Nós Autogerenciados.

Observe que todas as referências a 'nós' e 'nós de trabalho' na documentação do serviço Container Engine for Kubernetes abrangem nós autogerenciados, a menos que explicitamente indicado de outra forma.

Pods

Quando um aplicativo em execução em um nó de trabalho compreende vários contêineres, o Kubernetes agrupa os contêineres em uma única unidade lógica chamada pod para facilitar o gerenciamento e a descoberta. Os contêineres no pod compartilham o mesmo namespace de rede e o mesmo espaço de armazenamento, e podem ser gerenciados como objeto único pelo plano de controle de cluster. Um número de pods que fornece a mesma funcionalidade pode ser agrupado em um único conjunto lógico conhecido como serviço.

Os clusters do Kubernetes usam plug-ins da CNI (Contêiner Network Interface) para implementar a conectividade de rede para pods em execução nos nós de trabalho. Os plug-ins CNI configuram interfaces de rede, provisionam endereços IP e mantêm conectividade.

Para obter mais informações sobre pods, consulte a documentação do Kubernetes.

Serviços

No Kubernetes, serviço é uma abstração que define um conjunto lógico de pods e uma política pela qual acessá-los. O conjunto de pods direcionados por um serviço geralmente é determinado por um seletor.

Para algumas partes de um aplicativo (por exemplo, front-ends), talvez você queira expor um serviço em um endereço IP externo fora de um cluster.

Os ServiceTypes do Kubernetes permitem que você especifique o tipo de serviço que deseja expor. Um LoadBalancer ServiceType cria um balanceador de carga do Oracle Cloud Infrastructure em sub-redes de balanceadores de carga na sua VCN.

Para obter mais informações sobre serviços em geral, consulte a documentação do Kubernetes. Para obter mais informações sobre como criar serviços de balanceador de carga com o Serviço Container Engine for Kubernetes, consulte Definindo Serviços Kubernetes do Tipo LoadBalancer.

Plug-ins da CNI (Container Network Interface)

O Kubernetes adotou a especificação CNI (Contêiner Network Interface) para o gerenciamento de recursos de rede. O CNI consiste em uma especificação e bibliotecas para gravar plug-ins para configurar interfaces de rede em contêineres Linux, juntamente com vários plug-ins suportados.

Para obter mais informações, consulte a documentação do CNI no GitHub.

Arquivos de Manifesto (ou Especificações de Pod)

Um arquivo de manifesto do Kubernetes compreende instruções em um arquivo yaml ou json que especificam como implantar um aplicativo no nó ou nos nós em um cluster do Kubernetes. As instruções incluem informações sobre a implantação do Kubernetes, o serviço Kubernetes e outros objetos do Kubernetes a serem criados no cluster. O manifesto também é conhecido como uma especificação de pod ou como um arquivo deployment.yaml (embora outros nomes de arquivos sejam permitidos). Os parâmetros a serem incluídos em um arquivo de manifesto do Kubernetes estão descritos na documentação do Kubernetes.

Controladores de Admissão

Um controlador de admissão do Kubernetes intercepta solicitações autenticadas e autorizadas para o servidor de API do Kubernetes antes de admitir um objeto (como um pod) no cluster. Um controlador de admissão pode validar um objeto ou modificá-lo, ou ambos. Muitas funcionalidades avançadas do Kubernetes exigem um controlador de admissão ativado. Para obter mais informações, consulte a documentação do Kubernetes.

A versão do Kubernetes selecionada quando você cria um cluster usando o Container Engine for Kubernetes determina os controladores de admissão suportados por esse cluster. Para descobrir os controladores de admissão suportados, a ordem na qual eles são executados no servidor da API do Kubernetes e as versões do Kubernetes nas quais eles são suportados, consulte Controladores de Admissão Suportados.

Namespaces

Um cluster do Kubernetes pode ser organizado em namespaces para dividir os recursos do cluster entre diversos usuários. Inicialmente, um cluster tem os seguintes namespaces:

padrão, para recursos sem outro namespace
kube-system, para recursos criados pelo sistema Kubernetes
kube-node-lease, para um objeto de leasing por nó para ajudar a determinar a disponibilidade do nó
kube-public, geralmente usado para recursos que precisam estar acessíveis no cluster

Para obter mais informações sobre namespaces, consulte a documentação do Kubernetes.

Documentação do Oracle Cloud Infrastructure