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 Container Engine for Kubernetes (OKE).

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

Você só pode criar nós virtuais em clusters aprimorados. Você pode criar nós gerenciados em clusters básicos e avançados.

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 Virtuais e Pools de Nós Virtuais

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

Você só pode criar nós virtuais e pools de nós em clusters aprimorados.

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

Alguns recursos são suportados de maneira 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, em vez de 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 de pod, em vez de para os 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 está 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 dos pods 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 Pod Nativa da VCN é suportada (o plug-in de CNI da flannel 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 que os pods sejam criados.
    • O plug-in CNI do Pod Networking Nativo da VCN 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 de 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 qualquer 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 CNI do OCI VCN-Native Pod Networking.
Os daemonsets do Kubernetes não são suportados.

Por exemplo, não há suporte para o seguinte:

apiVersion: apps/v1
kind: DaemonSet
Reivindicações de volume persistentes (PVCs) não são suportadas. Nenhuma informação adicional.
Os provedores de rede que suportam recursos NetworkPolicy ao lado do 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.
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.

Pesquisas de prontidão e prontidão do tipo HTTP são suportadas.

sondagens HTTPS, gRPC e exec não são suportadas.

Pesquisas de inicialização não são suportadas.

probe.terminationGracePeriodSeconds não é suportado.

 Por exemplo, há suporte para o seguinte:
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3
No entanto, não há suporte para o seguinte:
livenessProbe:
  grpc:
     port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    scheme: "HTTPS"
startupProbe:
  httpGet:
    path: /healthz
    port:8080

O comando kubectl logs é suportado.

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

 Por exemplo, não há suporte para o seguinte:
kubectl logs -f workload1-589578899f-lwzm9
Contêineres efêmeros não são suportados. Nenhuma informação adicional.
Os contêineres 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, não há suporte para o seguinte:

volumes:
- name: test-volume
  hostPath:
    path: /data
No momento, o máximo de 1 volume do tipo emptyDir pode ser definido na especificação do pod. Nenhuma informação adicional.

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

  • hostIPC
  • hostNetwork
  • hostPid
  • hostName
  • podOS
  • Sobrecarga
  • setHostNameAsFqdn
  • shareProcessNamespace
 Por exemplo, não há suporte para o seguinte:
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 Pod não são suportados:

  • fsGroup
  • fsGroupChangePolicy
  • supplementalGroups
  • seLinuxOptions
  • sysctls
  • seccompProfile
 Por exemplo, não há suporte para o seguinte:
spec:
  securityContext:
    seLinuxOptions:
      type: dummy_container.proces

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

  • readOnlyRootFilesystem
  • allowPrivilegeEscalation:falso

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

  • allowPrivilegeEscalation:verdadeiro
  • privilegiado
  • procMount
  • recursos
 Por exemplo, não há suporte para o seguinte:
containers:
  - name: openssh-1
    securityContext:
      capabilities:
        add:
        - CAP_NET_ADMIN

Container.Port

  • IP do Host
  • Porta do Host
 Por exemplo, não há suporte para o seguinte:
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 estar em conflito com o intervalo NodePort (30000-32767). Por exemplo, não há suporte para o seguinte:
containers:
  - name: my-nginx
    image: nginx
    ports:
    - containerPort: 30002
Pod.Volumes.EmptyDirVolumeSource:SizeLimit Por exemplo, não há suporte para o seguinte:
emptyDir:
  sizeLimit: 500Mi
Pod.Volumes.EmptyDirVolumeSource:Médio - só pode ser "" ou "Memória" Por exemplo, não há suporte para o seguinte:
emptyDir:
  medium: "Memory1"

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

  • ConfigMapVolumeSource:KeyToPath:Modo
  • SecretVolumeSource:KeyToPath:Modo
  • ProjectedVolumeSource:ProjeçãoSecret:KeyToPath:Modo
  • ProjectedVolumeSource:ConfigMapProject:KeyToPath:Mode
 Por exemplo, não há suporte para o seguinte:
- 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:DefaultMode
  • ProjectedVolumeSource:DefaultMode
  • SecretVolumeSource:DefaultMode
 Por exemplo, não há suporte para o seguinte:
- name: workload-volume
    configMap:
      name: myconfigmap
      defaultMode: 0400
Resources.Requests não pode ser diferente de Resources.Limits Por exemplo, não há suporte para o seguinte:
resources:
  requests:
    cpu: 50m
    memory: 200Mi
  limits:
    cpu: 100m
    memory: 400Mi
Volumes:DownAPI:ResourceFieldRef Por exemplo, não há suporte para o seguinte:
resourceFieldRef:
  containerName: openssh
  resource: limits.cpu
TerminationGracePeriodSeconds Por exemplo, não há suporte para o seguinte:
terminationGracePeriodSeconds: 30
DeletionGracePeriodSeconds Por exemplo, não há suporte para o seguinte:
metadata:
  DeletionGracePeriodSeconds: 30
Contêiner Exec Por exemplo, não há suporte para o seguinte:
kubectl exec workload1-589578899f-lwzm9 -- sh
Comando Kubectl port-forward Use kubectl proxy em vez disso (consulte Diagnosticando e Solucionando Problemas de Pods e Serviços em Nós Virtuais Usando o proxy kubectl em vez do kubectl port-forward).
Solicitações UpdatePod com mutações para pod.spec.containers[].image Nenhuma informação adicional.
Propagação para pods de atualizações para configmaps e segredos montados Nenhuma informação adicional.
Métricas no nível do contêiner no ponto final de métricas do kubelet virtual Nenhuma informação adicional.
Contêiner:Subnúcleo ResourceRequirements Nenhuma informação adicional.
Contêiner stdin/stdinOnce, tty Nenhuma informação adicional.
Preserve os endereços IP do cliente quando externalTrafficPolicy: Local Nenhuma informação adicional.
Tipos ImagePullSecret diferentes de config e configJson Nenhuma informação adicional.
ProjectedVolumeSource:ServiceAccountTokenProjeção:Segundos de expiração Nenhuma informação adicional.
O comando kubectl attach para interagir com um processo que já está sendo executado dentro de um contêiner existente. Nenhuma informação adicional.

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

Alguns recursos e funcionalidades do serviço Container Engine for Kubernetes 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 serviço Container Engine for Kubernetes 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. Indisponível.
Dimensione automaticamente o número de nós virtuais. Indisponível.
Reservas de capacidade para provisionar nós virtuais. Indisponível.
Pods com formas Intel e GPU. Indisponível.
Rotação de credenciais, conforme descrito em Rotacionando Credenciais do Cluster Indisponível.

Implantações comuns não suportadas e suportadas de maneira 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 têm suporte diferente:

Implantação Observações
kube-proxy no namespace kube-system e o add-on do 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 Nginx Implante de maneira diferente ao usar nós virtuais (consulte Configurando o Exemplo de Controlador de Entrada).
Dimensionador Automático de Cluster do Kubernetes Não suportado ao usar nós virtuais.
Vertical Pod Autoscaler Não suportado ao usar nós virtuais.
Servidor de Métricas do Kubernetes Implante de maneira diferente ao usar nós virtuais (consulte Implantando o Kubernetes Metrics Server em um Cluster Usando o Kubectl).

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 gerenciado. 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 por fazer upgrade do Kubernetes nos nós gerenciados e por gerenciar a capacidade do cluster.

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

Você pode criar nós gerenciados e pools de nós em clusters básicos e avançados.

Recursos notáveis suportados de maneira diferente por nós gerenciados

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

  • Alocação de Recursos: A alocação de recursos está no nível do nó de trabalho, e não no nível do pod. Consequentemente, você especifica requisitos de recursos de CPU e memória para os nós de trabalho em um pool de nós, em vez de na especificação de pod.
  • Balanceamento de Carga: O balanceamento de carga ocorre entre os nós de trabalho, em vez de entre pods (como é o caso dos nós virtuais). Consequentemente, você não pode usar portas de preparação do pod para rotear o tráfego para conjuntos de backend do balanceador de carga em clusters com nós gerenciados.
  • Rede de Pod: O plug-in CNI de Rede de Pod Nativo da VCN e o plug-in CNI da flanela são suportados.
  • Dimensionamento Automático: O uso do Kubernetes Cluster Autoscaler e do Vertical Pod Autoscaler são suportados.

Recursos notáveis não suportados ou ainda não disponíveis ao usar nós gerenciados

Alguns recursos ainda não estão disponíveis ao usar nós gerenciados em vez de nós virtuais, incluindo:
  • Taints do Kubernetes