Documentação do Oracle Cloud Infrastructure

Comparando Nós Virtuais com Nós Gerenciados

Descubra as diferenças entre os nós virtuais e os nós gerenciados que você pode criar usando o Kubernetes Engine (OKE).

Ao criar um pool de nós com o Kubernetes Engine, você especifica o tipo de nós de trabalho a serem criados no pool de nós como um ou outro dos seguintes:

Só é possível criar nós virtuais em clusters aprimorados. É possível criar nós gerenciados tanto em clusters básicos como nos avançados.

Todas as referências a 'nós' e 'nós do colaborador' na documentação do Kubernetes Engine se referem a nós virtuais e nós gerenciados, a menos que seja declarado explicitamente em contrário.

Nós virtuais e grupos de nós virtuais

Nós virtuais são executados na tenancy do Kubernetes Engine. Você cria nós virtuais criando um pool de nós virtuais. Os nós virtuais e os pools de nós virtuais são 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 do plano de dados e gerenciar a capacidade dos clusters.

Só é possível criar nós virtuais e pools de nós em clusters aprimorados.

Recursos notáveis suportados de forma diferente por nós virtuais

Alguns recursos são suportados de forma diferente ao usar nós virtuais em vez de nós gerenciados:

  • Alocação de Recursos: A alocação de recursos está no nível do pod, e não no nível do nó de trabalho. Consequentemente, você especifica requisitos de recursos de CPU e memória (como solicitações e limites) na especificação do pod, em vez dos nós de trabalho em um pool de nós. Consulte Recursos Alocados a Pods Provisionados por Nós Virtuais.

  • Balanceamento de Carga: O balanceamento de carga ocorre entre pods, em vez de entre nós de trabalho (como é o caso dos nós gerenciados). Em clusters com nós virtuais, o gerenciamento da lista de segurança do balanceador de carga nunca é ativado e você sempre precisa configurar manualmente as regras de segurança. Os balanceadores de carga distribuem o tráfego entre os endereços IP e uma porta de nó designada. Ao estabelecer conexão com pods em execução em nós virtuais, use a sintaxe <pod-ip>:<nodeport>, em vez de <node-ip>:<nodeport>. Se você usar diferentes sub-redes para pods e nós, configure a entrada da porta do nó na sub-rede do pod.
  • Rede de Pod: Somente a Rede de Pods Nativa da VCN é suportada (o plug-in de flannel CNI não é suportado). Além disso, o suporte é um pouco diferente ao usar nós virtuais:
    • Somente uma VNIC é anexada a cada nó virtual.
    • Os endereços IP não são pré-alocados antes da criação dos pods.
    • O plug-in VCN-Native Pod Networking CNI não é mostrado como executado no namespace kube-system.
    • Como apenas a Rede de Pod Nativa da VCN é suportada, a tabela de roteamento da sub-rede do pod deve ter regras de roteamento definidas para um gateway NAT (não um gateway de internet) e um gateway de serviço.
  • Dimensionamento Automático: Os nós virtuais são dimensionados automaticamente para suportar 500 pods. Como a Oracle gerencia os recursos subjacentes para nós virtuais, é mais fácil trabalhar com o Kubernetes Horizontal Pod Autoscaler. Não é necessário usar o Kubernetes Cluster Autoscaler (que ainda não é suportado com nós virtuais em nenhum caso). O Kubernetes Vertical Pod Autoscaler não é suportado com nós virtuais.

Recursos e recursos notáveis do Kubernetes não suportados ao usar nós virtuais

Alguns recursos e funcionalidades do Kubernetes não são suportados ou ainda não estão disponíveis ao usar nós virtuais em vez de nós gerenciados.

Recursos do Kubernetes não suportados Informações adicionais
Flannel e outros plug-ins CNI de terceiros não são suportados. Os nós virtuais só suportam o plug-in da CNI de Rede do Pod Nativo da VCN do OCI.
Os daemonsets do Kubernetes não são suportados.

Por exemplo, o seguinte não é suportado:

apiVersion: apps/v1
kind: DaemonSet
Não há suporte para reivindicações de volume persistentes (PVCs). Nenhuma informação adicional.
Os provedores de rede que suportam recursos NetworkPolicy juntamente com o plug-in CNI usado no cluster (como Calico e Cilium) não são suportados. Nenhuma informação adicional.
As políticas de rede (o recurso NetworkPolicy do Kubernetes) não são suportadas. Nenhuma informação adicional.
Os produtos de malha de serviço não são suportados. Produtos como Oracle Cloud Infrastructure Service Mesh e Istio Service Mesh não são suportados.

As investigações de disponibilidade e disponibilidade do tipo HTTP são suportadas.

As investigações HTTPS e exec são suportadas.

Sondagens de inicialização são suportadas.

As investigações gRPC não são suportadas.

probe.terminationGracePeriodSeconds não é suportado.

 Por exemplo, estes itens são suportados:
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    scheme: "HTTPS"
startupProbe:
  httpGet:
    path: /healthz
    port:8080
No entanto, o seguinte não é suportado:
livenessProbe:
  grpc:
     port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

O comando kubectl logs é suportado.

O comando kubectl logs -p é suportado.

O comando kubectl logs -f não é suportado.

 Por exemplo, estes itens são suportados:
kubectl logs workload1-589578899f-lwzm9
kubectl logs workload1-589578899f-lwzm9 -p
No entanto, o seguinte não é suportado:
kubectl logs workload1-589578899f-lwzm9 -f
Contêineres efêmeros não são suportados. Nenhuma informação adicional.
Os recipientes de inicialização não são suportados. Nenhuma informação adicional.

Os seguintes Tipos de Volume são suportados:

  • emptyDir
  • ConfigMap
  • Segredo

  • ProjectedVolume dos seguintes tipos:

    • ServiceAccount
    • ConfigMap
    • Segredo

Os seguintes Tipos de Volume não são suportados:

  • hostPath
  • persistentVolumeClaim
  • local
  • nfs
  • iscsi
  • cephfs

Por exemplo, o seguinte não é suportado:

volumes:
- name: test-volume
  hostPath:
    path: /data
No momento, é possível definir no máximo 1 volume do tipo emptyDir na especificação do pod. Nenhuma informação adicional.

Os seguintes campos de Pod não são suportados:

  • hostIPC
  • hostNetwork
  • hostPid
  • hostName
  • podOS
  • Overhead
  • setHostNameAsFqdn
  • shareProcessNamespace
 Por exemplo, o seguinte não é suportado:
spec:
  hostIPC: true
  hostNetwork: true
  hostPID: false
  setHostnameAsFQDN : true
  shareProcessNamespace : true

Os seguintes contextos de segurança de Pod são suportados:

  • runAsNonRoot
  • runAsUser
  • runAsGroup

Os seguintes contextos de segurança do Pod não são suportados:

  • fsGroup
  • fsGroupChangePolicy
  • supplementalGroups
  • seLinuxOptions
  • sysctls
  • seccompProfile
 Por exemplo, o seguinte não é suportado:
spec:
  securityContext:
    seLinuxOptions:
      type: dummy_container.proces

Os seguintes contextos de segurança do Contêiner são suportados:

  • readOnlyRootFilesystem
  • allowPrivilegeEscalation:falso
  • recursos

Os seguintes contextos de segurança do Contêiner não são suportados:

  • allowPrivilegeEscalation:verdadeiro
  • privilegiado
  • procMount
 Por exemplo, o seguinte é suportado:
containers:
  - name: openssh-1
    securityContext:
      capabilities:
        add:
        - CAP_NET_ADMIN
No entanto, o seguinte não é suportado:
containers:
  - name: openssh-1
    securityContext:
      procMount: Unmasked

Container.Port

  • IP do Host
  • Porta do Host
 Por exemplo, o seguinte não é suportado:
ports:
  - name: test
    containerPort: 81
    hostPort: 80

Contêiner

  • TerminationMessagePolicy
  • TerminationMessagePath
  • VolumeDevices
  • VolumeMount.MountPropagation
  • Expressão VolumeMount.Subpath
 Observe que o Kubernetes adiciona TerminationMessagePolicy e TerminationMessagePath por padrão.
O intervalo de portas do contêiner (1, 65535) não pode entrar em conflito com o intervalo NodePort (30000-32767). Por exemplo, o seguinte não é suportado:
containers:
  - name: my-nginx
    image: nginx
    ports:
    - containerPort: 30002
Pod.Volumes.EmptyDirVolumeSource:Limite de Tamanho Por exemplo, o seguinte não é suportado:
emptyDir:
  sizeLimit: 500Mi
Pod.Volumes.EmptyDirVolumeSource:Médio - só pode ser "" ou "Memória" Por exemplo, o seguinte não é suportado:
emptyDir:
  medium: "Memory1"

Pod:Volumes - O modo deve ser especificado como 0644 para o seguinte:

  • ConfigMapVolumeSource:KeyToPath:Modo
  • SecretVolumeSource:KeyToPath:Modo
  • ProjectedVolumeSource:SecretProjection:Caminho KeyTo:Modo
  • ProjectedVolumeSource:ConfigMapProjection:KeyToPath:Modo
 Por exemplo, o seguinte não é suportado:
- name: myconfigmap
  configMap:
    name: kube-root-ca.crt
    items:
    - key: ca.crt
      path: abc
      mode: 0400

Pod:Volumes - se DefaultMode for especificado para o seguinte, DefaultMode deverá ser 0644:

  • ConfigMapVolumeSource:ModoPadrão
  • ProjectedVolumeSource:ModoPadrão
  • SecretVolumeSource:ModoPadrão
 Por exemplo, o seguinte não é suportado:
- name: workload-volume
    configMap:
      name: myconfigmap
      defaultMode: 0400
Resources.Requests não pode ser diferente de Resources.Limits Por exemplo, o seguinte não é suportado:
resources:
  requests:
    cpu: 50m
    memory: 200Mi
  limits:
    cpu: 100m
    memory: 400Mi
Volumes:DownwardAPI:ResourceFieldRef Por exemplo, o seguinte não é suportado:
resourceFieldRef:
  containerName: openssh
  resource: limits.cpu
TerminationGracePeriodSeconds Por exemplo, o seguinte não é suportado:
terminationGracePeriodSeconds: 30
DeletionGracePeriodSeconds Por exemplo, o seguinte não é suportado:
metadata:
  DeletionGracePeriodSeconds: 30
Executar Contêiner Por exemplo, o seguinte não é suportado:
kubectl exec workload1-589578899f-lwzm9 -- sh
Comando port-forward Kubectl Em vez disso, use kubectl proxy (consulte Diagnosticando e Solucionando Problemas de Pod e Serviço em Nós Virtuais Usando proxy kubectl em Vez de encaminhar porta kubectl).
Solicitações UpdatePod com mutações para pod.spec.containers[].image Nenhuma informação adicional.
Propagação para pods de atualizações para mapas de configuração e segredos montados Nenhuma informação adicional.

As seguintes métricas no nível do contêiner no ponto final de métricas do kubelet virtual são suportadas:

  • container_cpu_usage_seconds_total
  • container_memory_working_set_bytes
Outras métricas no nível do contêiner no ponto final de métricas do kubelet virtual não são suportadas.		 Nenhuma informação adicional.
Contêiner:Subnúcleo de Necessidades de Recurso Nenhuma informação adicional.
Contêiner stdin/stdinOnce, tty Nenhuma informação adicional.
Preservar endereços IP do cliente quando externalTrafficPolicy: Local Nenhuma informação adicional.
Tipos ImagePullSecret diferentes de config e configJson Nenhuma informação adicional.
ProjectedVolumeSource:ServiceAccountTokenProjection:Segundos de Expiração Nenhuma informação adicional.
O comando kubectl attach para interagir com um processo que já está em execução dentro de um contêiner existente. Nenhuma informação adicional.

Recursos e recursos notáveis do Kubernetes Engine (OKE) não suportados ao usar nós virtuais

Alguns recursos e funcionalidades do Kubernetes Engine não estão disponíveis, ou ainda não estão disponíveis, ao usar nós virtuais em vez de nós gerenciados.

Recursos do Kubernetes Engine não suportados Informações adicionais
Conexões SSH com nós de trabalho (incluindo por meio de um bastion) Não disponível.
Uso de scripts cloud-init personalizados Não disponível.
Script do Node Doctor Não disponível.
Suporte para versões do Kubernetes anteriores à versão 1.25 Os nós virtuais exigem que o cluster esteja executando pelo menos o Kubernetes versão 1.25.
Clusters mistos, contendo nós virtuais e nós gerenciados. Ainda não está disponível
Dimensionamento automático do número de nós virtuais. Ainda não está disponível
Reservas de capacidade para provisionar nós virtuais. Ainda não está disponível
Pods com formas Intel e GPU. Ainda não está disponível
Rotação de credenciais, conforme descrito em Rotacionando Credenciais do Cluster Ainda não está disponível

Implantações comuns não suportadas e suportadas de forma diferente ao usar nós virtuais

As seguintes implantações comuns não são suportadas ao usar nós virtuais em vez de nós gerenciados ou são suportadas de maneira diferente:

Implantação Observações
kube-proxy no namespace kube-system e no add-on de cluster kube-proxy O kube-proxy é executado em pods programados em nós virtuais, mas não é implantado no namespace kube-system.
Painel do Kubernetes Não suportado ao usar nós virtuais.
Controlador de entrada do Nginx Implante de forma diferente ao usar nós virtuais (consulte Configurando o Exemplo de Controlador de Entrada).
do Kubernetes Cluster Não suportado ao usar nós virtuais.
Escalador de Pod Vertical Não suportado ao usar nós virtuais.
Kubernetes Metrics Server Implante de maneira diferente ao usar nós virtuais (consulte Implantando o Servidor de Métricas do Kubernetes em um Cluster).

Nós Gerenciados e Pools de Nós Gerenciados

Nós gerenciados são executados em instâncias de computação (bare metal ou máquina virtual) em sua tenancy. Você cria nós gerenciados criando um pool de nós gerenciados. Nós gerenciados e pools de nós gerenciados são 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 pelo upgrade do Kubernetes em nós gerenciados e pelo gerenciamento da capacidade do cluster.

Ao usar nós gerenciados, você paga pelas instâncias de computação que executam aplicativos.

É possível criar nós gerenciados e pools de nós tanto em clusters básicos como nos avançados.

Para obter mais informações, consulte Comparando Nós Gerenciados com Nós Virtuais