Limitações e cotas do serviço

Analise as limitações e cotas do serviço que se aplicam aos clusters e saiba quais limites podem ser ajustados quando necessário.

Se você previr antecipadamente que atingirá qualquer uma das limitações do Red Hat OpenShift on IBM Cloud a seguir, entre em contato com o suporte IBM e forneça o ID do cluster, o novo limite de cotas e a região em seu chamado de suporte.

Limitações de cotas e de serviço

O Red Hat OpenShift on IBM Cloud vem com as limitações de serviço e cotas a seguir que se aplicam a todos os clusters, independentemente de qual provedor de infraestrutura você planeja usar. Tenha em mente que as limitações de cluster clássico e VPC também se aplicam.

Para visualizar limites de cotas em recursos relacionados ao cluster em sua conta da IBM Cloud, use o comando ibmcloud oc quota ls.

Red Hat OpenShift on IBM Cloud limitações
Categoria Descrição
Limites de taxa de API 200 solicitações por 10 segundos para a API do Red Hat OpenShift on IBM Cloud por meio de cada endereço IP de origem exclusivo.
Implementação do aplicativo Os apps que você implementa e os serviços que você integra com o seu cluster devem ser capazes de executar no sistema operacional dos nós do trabalhador.
Plug-in de rede Calico A mudança do plug-in Calico, de componentes ou das configurações padrão do Calico não é suportada. Por exemplo, não implemente uma nova versão de plug-in Calico, nem modifique os conjuntos de daemons ou implementações para os componentes do Calico, recursos padrão IPPool ou nós do Calico. Em vez disso, é possível seguir a documentação para criar um NetworkPolicy ou GlobalNetworkPolicy do Calico, mudar a MTU do Calico ou desativar o plug-in de mapa da porta para a CNI do Calico.
Cota de cluster Não é possível exceder 100 clusters por região e por provedor de infraestrutura. No entanto, a partir de 01 de janeiro de 2024, as cotas são aumentadas incrementalmente antes de atingir 100. Se você precisar mais do recurso, entre em contato com o suporte IBM. No ticket de suporte, inclua o novo limite de cota para a região e o provedor de infraestrutura de sua preferência. Para listar cotas, execute ibmcloud quota ls..
Kubernetes Certifique-se de revisar as Limitações do projeto Kubernetes.
Provedor de KMS A customização dos endereços IP que são permitidos para conexão à sua instância do IBM® Key Protect for IBM Cloud® não é suportada.
Red Hat OpenShift Certifique-se de verificar as limitações do OpenShift Container Platform para a sua versão.
Logs de pod do Kubernetes Para verificar os logs para pods de app individuais, é possível usar a linha de comandos para executar oc logs <pod name>. Não use o painel do Kubernetes para transmitir os logs para os seus pods, o que pode causar uma interrupção em seu acesso ao painel do Kubernetes.
Monitoring

-Porque a IBM gerencia seu cluster mestre, o evento alertando para o mestre é desativado. A IBM monitora seu cluster mestre e corrige problemas conforme eles são detectados. Por esta razão, na perspectiva de Administrador do Red Hat OpenShift, você pode ver uma mensagem Not available para o status do plano de controle.

  • O gerenciador de alertas integrado Prometheus inclui duas regras que são exibidas como alertas ativos em um estado FIRING: KubeControllerManagerDown e KubeSchedulerDown. Esses componentes são parte do cluster mestre gerenciado pela IBM, portanto, é possível ignorar esses alertas.
Sistema operacional Os nós do trabalhador devem executar um dos sistemas operacionais suportados Não é possível criar um cluster com nós do trabalhador que executam diferentes tipos de sistemas operacionais.. Para obter mais informações, consulte as informações da versão do Red Hat OpenShift on IBM Cloud.
Catálogo do OperatorHub Para usar o catálogo OperatorHub em clusters privados, consulte Desativando OperatorHub e espelhando imagens de origem do catálogo para o icr.io.
Instâncias de pod É possível executar 110 pods por nó do trabalhador. Se você tiver nós do trabalhador com 11 núcleos de CPU ou mais, será possível suportar 10 pods por núcleo, até um limite de 250 pods por nó do trabalhador. O número de pods inclui os pods kube-system e ibm-system que são executados no nó do trabalhador. Para melhorar o desempenho, considere limitar o número de pods executado por núcleo de cálculo para não sobreutilizar o nó do trabalhador. Por exemplo, em um nó do trabalhador com um tipo b3c.4x16, é possível executar 10 pods por núcleo que usam não mais que 75% da capacidade total do nó do trabalhador.
Descontinuado Senha única baseada em tempo (TOTP) Para usar o TOTP, certifique-se de ativar a autenticação de diversos fatores (MFA) para sua conta inteira da IBM Cloud. Se o MFA for ativado apenas para alguns usuários, mas não no nível da conta, erros de autenticação poderão ocorrer.
Cota do nó do trabalhador Um máximo de 500 nós de trabalho para todas as contas criadas antes de 1º de janeiro de 2024. Para contas criadas a partir dessa data, a cota máxima é 200, após um período de cotas mais baixas. As cotas se aplicam por cluster provedor de infraestrutura. Se você precisar mais do recurso, entre em contato com o suporte IBM. No ticket de suporte, inclua o novo limite de cota para a região e o provedor de infraestrutura de sua preferência. Para listar as execuções de cotas, execute o comando ibmcloud ks quota ls``.
Tamanho do conjunto do trabalhador É necessário que haja sempre, no mínimo, 2 nós no seu cluster. Por causa da cota do nó do trabalhador, você está limitado no número de conjuntos de trabalhadores por cluster e no número de nós do trabalhador por conjunto de trabalhadores. Por exemplo, com a cota de nó do trabalhador padrão de 500 por região, é possível ter até 500 conjuntos de trabalhadores de um nó do trabalhador cada um em uma região com apenas um cluster. Ou ainda, você pode ter 1 de conjunto de trabalhadores com até 500 nós do trabalhador em uma região com apenas 1 cluster.
Red Hat Enterprise Linux CoreOS A quantidade máxima de zonas adicionadas a um cluster é 12. Por exemplo, 3 pools de trabalho do RHCOS com 3 zonas cada um representarão 9/12 da cota desse cluster.
Número de nós do trabalhador Os clusters podem ter um máximo de 500 nós de trabalho.
Nomenclatura do cluster Para assegurar que o subdomínio do Ingress e o certificado estejam corretamente registrados, os primeiros 24 caracteres dos nomes dos clusters deverão ser diferentes. Se você criar e excluir clusters com o mesmo nome ou com nomes que tenham os mesmos primeiros 24 caracteres cinco vezes ou mais dentro de sete dias, como, por exemplo, para propósitos de automação ou teste, você poderá atingir o Limite de taxa de certificado duplicado do Let's Encrypt.
Grupos de recursos Um cluster pode ser criado em apenas um grupo de recursos que não pode ser mudado posteriormente. Se você criar um cluster no grupo de recursos incorreto, deverá excluir o cluster e recriá-lo no grupo de recursos correto. Além disso, se for necessário usar o comando ibmcloud oc cluster service bind para realizar a integração com um serviço do IBM Cloud, esse serviço deverá estar no mesmo grupo de recursos que o cluster. Serviços que não utilizam grupos de recursos, como IBM Cloud Container Registry, ou que não precisam de vinculação de serviço, como IBM Cloud Logs, funcionam mesmo que o cluster esteja em um grupo de recursos diferente.

Limitações de cluster do Red Hat OpenShift on IBM Cloud

Analise as limitações específicas dos clusters do Red Hat OpenShift. Tenha em mente que as limitações de serviço e cluster clássico ou cluster VPC também se aplicam.

limitações do cluster do OpenShift Container Platform
Categoria Descrição
Ajuste automático de escala de cluster O autoscaler do cluster do Red Hat OpenShift, acessível pelo console Red Hat OpenShift Administração > Configurações do cluster, ou o objeto ClusterAutoscaler da API autoscaling.openshift.io/v1 não são suportados. Em vez disso, use o plug-in do Helm ibm-iks-cluster-autoscaler.
Atualizações de cluster Deve-se atualizar o cluster usando a API, a CLI ou as ferramentas do console do Red Hat OpenShift on IBM Cloud. Não é possível atualizar sua versão de cluster por meio das ferramentas do OpenShift Container Platform, como o console da web do Red Hat OpenShift.
Logs do contêiner Ao usar um operador de criação de log de contêiner, como o Fluentd, para enviar logs para uma pilha do ElasticSearch, deve-se atualizar a implementação de criação de log do cluster para usar a classe de armazenamento ibmc-block-gold.
Clusters privados

Dependendo do provedor de infraestrutura, suas opções para clusters privados são limitadas.

  • VPC: Ao criar seu cluster VPC no console da IBM Cloud, seu cluster tem um terminal em serviço de nuvem público e privado. Se você deseja apenas um endpoint de serviço em nuvem privada, deve criar o cluster pela CLI e incluir a opção --disable-public-service-endpoint . Se você incluir essa opção, seu cluster será criado com roteadores e controladores Ingress que, por padrão, expõem seus aplicativos apenas na rede privada. Se posteriormente você quiser expor apps para uma rede pública, deverá criar manualmente os roteadores públicos e os controladores do Ingress.
  • Clássico: É possível ativar o terminal em serviço de nuvem pública e privada ou o terminal em serviço de nuvem pública apenas, mas não é possível ativar apenas o terminal em serviço de nuvem privada. Após a criação de cluster, não será mais possível mudar os terminais em serviço.
Criação de log Para configurar uma pilha composta por OpenShift Container Platform Elasticsearch, Fluentd e Kibana(EFK), consulte a seção sobre a instalação do operador de registro do cluster.
Catálogo de serviços O catálogo de serviços não é suportado. Use Operadores. Não use o OperatorHub para instalar o catálogo de serviços.
Malha de serviço O complemento gerenciado Istio não é suportado. Em vez disso, use o operador de malha de serviço Red Hat. Nota: a configuração padrão do IBM Cloud dos roteadores ativa a rede do host, que não é compatível com a política de rede de malha de serviço. Para que o Ingress da malha de serviços funcione, aplique uma política de rede.

Limitações de cluster clássico

Os clusters de infraestrutura clássicos no Red Hat OpenShift on IBM Cloud são liberados com as limitações a seguir.

Cálculo

Tenha em mente que as limitações de serviço também se aplicam.

Limitações de cálculo do cluster clássico
Categoria Descrição
Instâncias reservadas A capacidade reservada e as instâncias reservadas não são suportadas.
Tipos de nó do trabalhador Os nós de trabalho estão disponíveis em determinados tipos de recursos de computação.
Acesso ao host do nó do trabalhador Por segurança, não é possível emitir SSH no host de cálculo de nó do trabalhador.

Rede

Tenha em mente que as limitações de serviço também se aplicam.

Limitações de rede do cluster clássico
Categoria Descrição
ALBs do Ingress
Balanceadores de carga de rede (NLB)
  • Não é possível criar balanceadores de carga de rede da versão 2.0 (NLB 2.0) para expor seus apps.
  • Não é possível criar subdomínios para NLBs privados.
  • É possível registrar até 128 subdomínios. Esse limite pode ser aumentado solicitando um caso de suporte.
Console da web do Red Hat OpenShift O console da web não pode ser exposto na rede privada em clusters que possuem terminais públicos e privados. Se você quiser disponibilizar o console da web na rede privada, seu cluster não pode ter um endpoint público ativado.
Somente VLANs privadas Os balanceadores de carga de rede privada (NLBs) não podem ser registrados com o servidor de nomes de domínio (DNS), portanto, o cluster não pode ser criado com apenas uma interface de rede privada. Os nós do trabalhador devem estar conectados a VLANs públicas e privadas. Ainda é possível criar um serviço privado para expor seus apps somente na rede privada.
Terminais em serviço Ao criar um cluster, é possível ativar o terminal em serviço de nuvem pública e privada ou o terminal em serviço de nuvem pública apenas, mas não é possível ativar apenas o terminal em serviço de nuvem privada. Após a criação de cluster, não será mais possível mudar os terminais em serviço.
Sub-redes por VLAN Cada VLAN tem um limite de 40 sub-redes.

Storage

Tenha em mente que as limitações de serviço também se aplicam.

Limitações de armazenamento de cluster clássico
Categoria Descrição
Instâncias de volume É possível ter um total de 250 volumes de arquivo de infraestrutura e de armazenamento de bloco do IBM Cloud por conta. Se você montar mais do que essa quantidade, poderá receber uma mensagem de “ out of capacity ” ao provisionar volumes persistentes. Para obter mais perguntas frequentes, consulte os documentos sobre armazenamento de arquivos e blocos. Se desejar montar mais volumes, entre em contato com o IBM. Em seu ticket de suporte, inclua o seu ID de conta e o novo arquivo ou cota de volume de armazenamento de bloco que você deseja.
Portworx Revise as limitações do Portworx.
Armazenamento de arquivos Devido à maneira como o armazenamento de arquivo NFS do IBM Cloud configura as permissões de usuário do Linux, podem ser encontrados erros ao usar o armazenamento de arquivo. Nesse caso, talvez seja necessário configurar Red Hat OpenShift Security Context Constraints ou usar um tipo de armazenamento diferente.

Acesso de usuário clássico

Tenha em mente que as limitações de serviço também se aplicam.

Limitações de acesso do usuário do cluster clássico
Categoria Descrição
Acesso de endereço IP A restrição de acesso para usuários específicos por meio da ativação do acesso ao endereço IP não é compatível com o site Red Hat OpenShift on IBM Cloud. Se quiser restringir o acesso do usuário ou restringir quais serviços e VPCs um usuário pode acessar, considere a restrição baseada em contexto.

Limitações do cluster de VPC

Os clusters de VPC no IBM Cloud Kubernetes Service são liberados com as limitações a seguir. Além disso, todas as cotas de VPC, limites de VPC, limitações de serviço de VPC e limitações de serviço regulares subjacentes se aplicam.

Cálculo

Tenha em mente que as limitações de serviço também se aplicam.

Limitações de cálculo do cluster de VPC
Categoria Descrição
Clusters por VPC As VPCs são limitadas a 25 clusters cada.
Criptografia Os discos secundários de seus nós do trabalhador são criptografados em repouso por padrão pelo provedor de infraestrutura de VPC subjacente. No entanto, não é possível trazer sua própria criptografia para as instâncias do servidor virtual subjacente.
Local Os clusters VPC estão disponíveis apenas em determinadas regiões com várias zonas.
Virtual Private Cloud Consulte Limitações e cotas.
Cotas de recursos de VPC A VPC gerencia cotas de memória vCPU,, GPU, armazenamento de instância e recursos otimizados de armazenamento de instância por conta. Quando você provisiona nós de trabalho de instância de servidor virtual (VSI) na infraestrutura pública, esses recursos são contabilizados nas cotas da sua conta VPC. Se você atingir um limite de cota, o provisionamento do nó de trabalho falhará. Para visualizar suas cotas e uso atuais, consulte Visualização de métricas de recursos de VPC. Para solicitar um aumento de cota, abra um caso de suporte com a VPC. Para obter mais informações, consulte as cotas do VPC.

Observação: Atualmente, essa gestão de cotas se aplica apenas aos nós de trabalho VSI em infraestrutura pública. O Red Hat OpenShift on IBM Cloud continua a gerenciar as cotas para nós de trabalho em hosts dedicados e bare metal.
Tipos de nó do trabalhador Apenas determinados tipos de instâncias estão disponíveis para máquinas virtuais de nós de trabalho e nós de trabalho em bare metal.
Acesso ao host do nó do trabalhador Por segurança, não é possível emitir SSH no host de cálculo de nó do trabalhador.
Atualizações do nó do trabalhador As ações de atualização dos workers do VPC dependem do tipo de worker. Para os usuários de máquinas físicas (bare metal) do VPC, é possível usar o comando ibmcloud oc worker reload para aplicar uma recarga. Para os trabalhadores de instâncias de servidor virtual (VPC), use o comando ibmcloud oc worker replace . Se você substituir vários nós do trabalhador ao mesmo tempo, eles serão excluídos e substituídos simultaneamente, não um por um. Certifique-se de que você tenha capacidade suficiente em seu cluster para remarcar suas cargas de trabalho antes de substituir os nós do trabalhador.

Rede

Tenha em mente que as limitações de serviço também se aplicam.

Limitações de rede de cluster de VPC
Categoria Descrição
Comprimento da URL do app A resolução de DNS é gerenciada pelo terminal privado virtual (VPE) do cluster, que pode resolver URLs de até 130 caracteres. Ao expor apps em seu cluster com URLs, como o subdomínio do Ingress ou as rotas do Red Hat OpenShift, assegure-se de que elas tenham 130 caracteres ou menos.
Velocidades de rede Velocidades de rede de perfil de VPC referem-se às velocidades das interfaces de nós do trabalhador. A largura de banda disponível para instâncias de VPC é compartilhada entre o armazenamento e o tráfego de rede. Por padrão, a alocação de armazenamento é de 25% da largura de banda máxima. A velocidade da rede, conforme mostrado nas tabelas abaixo, é a largura de banda de rede disponível para um trabalhador com uma única interface de rede após a dedução da alocação padrão de 25% da largura de banda de armazenamento.
NodePort Será possível acessar um app por meio de um NodePort apenas se você estiver conectado à sua rede privada VPC, como por meio de uma conexão VPN. Para acessar um app por meio da Internet, deve-se usar um balanceador de carga do VPC ou um serviço Ingress como alternativa.
Rede de pod As listas de controle de acesso (ACLs) de VPC filtram o tráfego de entrada e de saída para o seu cluster no nível de sub-rede e os grupos de segurança filtram o tráfego de entrada e de saída para o seu cluster no nível de nós do trabalhador. Para controlar o tráfego dentro do cluster em nível de pod para pod, não é possível usar grupos de segurança de VPC ou ACLs. Em vez disso, use Políticas de rede do Kubernetes e do Calico, que podem controlar o tráfego de rede de nível de pod que usa IP em encapsulamento de IP.
Gateway público Se o terminal de serviço público estiver ativado, você deverá conectar um gateway público em cada sub-rede de VPC para que seus nós do trabalhador possam se comunicar na rede pública. Os componentes padrão do Red Hat OpenShift, como o console da web e o OperatorHub, requerem acesso à rede pública.
Terminais em serviço Ao criar seu cluster de VPC no console da IBM Cloud, seu cluster tem um terminal em serviço de nuvem pública e privada. Se você deseja apenas um endpoint de serviço em nuvem privada, deve criar o cluster pela CLI e incluir a opção --disable-public-service-endpoint . Se você incluir essa opção, seu cluster será criado com roteadores e controladores Ingress que, por padrão, expõem seus aplicativos apenas na rede privada. Se posteriormente você quiser expor aplicativos para uma rede pública, deverá criar manualmente roteadores públicos e controladores do Ingress.
Subnets
  • Consulte as limitações de rede do VPC.
  • Não exclua as sub-redes que você vincula ao seu cluster durante a criação do cluster ou ao adicionar nós de trabalho em uma zona. Se você excluir uma sub-rede do VPC que o seu cluster usou, qualquer balanceador de carga que use os endereços IP da sub-rede poderá ter problemas e poderá não ser possível criar novos balanceadores de carga.
Balanceador de carga da VPC Consulte as Limitações do balanceador de carga VPC.

Storage

Tenha em mente que as limitações de serviço também se aplicam.

Limitações de armazenamento de cluster de VPC
Categoria Descrição
Classe de armazenamento para tamanhos de perfil Para obter mais informações, consulte Perfis de volumes disponíveis
Tipos suportados É possível configurar o IBM Cloud Object Storage e o Cloud Databases apenas.
Conexões de volume Consulte Limites de anexo de volume.
Portworx Revise as limitações do Portworx.
Block Storage for VPC A classe de armazenamento padrão nos clusters VPC não pode ser alterada. No entanto, é possível criar sua própria classe de armazenamento..

Acesso do usuário VPC

Tenha em mente que as limitações de serviço também se aplicam.

Limitações de acesso do usuário do cluster VPC
Categoria Descrição
Acesso de endereço IP A restrição de acesso para usuários específicos por meio da ativação do acesso ao endereço IP não é compatível com o site Red Hat OpenShift on IBM Cloud. Se quiser restringir o acesso do usuário ou restringir quais serviços e VPCs um usuário pode acessar, considere a restrição baseada em contexto.

Limitações de cluster do Satellite

Revise as limitações a seguir para os clusters Red Hat OpenShift on IBM Cloud que você cria em um local do Satellite. Tenha em mente que as limitações de serviço também se aplicam.

Satellite limitações do cluster
Categoria Descrição
Componentes de cluster Revise os complementos gerenciados não suportados para clusters do Red Hat OpenShift em uma localização do Satellite. Por exemplo, o escalador automático do cluster e o Istio não são suportados.
Rede
  • Por padrão, não há controlador de balanceador de carga implantado com clusters Satellite e, portanto, os serviços Kubernetes LoadBalancer não são provisionados por padrão. Você pode integrar sua própria solução de balanceador de carga em clusters, como o MetalLB.
  • Os hosts que executam os nós de trabalho de seu cluster devem atender aos requisitos de rede do host e aos requisitos específicos do provedor, como AWS, Azure, GCP, e IBM Cloud (somente para fins de teste e demonstração).
  • Como o encapsulamento VXLAN é necessário para o tráfego entre pods que estão em diferentes nós de trabalho, as velocidades de transferência de dados entre pods em diferentes nós de trabalho podem ser mais lentas do que a capacidade de rede dos hosts.
Armazenamento para hosts do nó do trabalhador Consulte Armazenamento de host e dispositivos conectados.
Armazenamento para apps Nenhum provedor de armazenamento é instalado em seus clusters Satellite por padrão. Portanto, nenhuma classe de armazenamento do Kubernetes pré-configurada é configurada por padrão em seus clusters para armazenar seus dados do aplicativo em um volume persistente do Kubernetes que é suportado pelo dispositivo de armazenamento. Para obter opções para configurar um provedor de armazenamento, consulte Entendendo modelos de armazenamento do Satellite.
Nós do trabalhador Os nós do trabalhador são executados em hosts em seus próprios ambientes de infraestrutura. Os hosts devem atender aos requisitos de host e aos específicos do provedor, como para AWS, Azure, GCP e IBM Cloud (fins de teste e demonstração apenas). Você é responsável por gerenciar o ciclo de vida da infraestrutura dos seus hosts, incluindo a adição e a atualização de nós de trabalho. Como tal, operações de nós do trabalhador, como os comandos ibmcloud oc worker add, update, replace, reload não são compatíveis.
Conjuntos de trabalhadores Para usar operações como resize, seu conjunto de trabalhadores usa rótulos de host que devem corresponder hosts disponíveis (não designados) na localização do Satellite.
Clusters de nó único. Qualquer cluster com menos de três nós do Trabalhador não tem alta disponibilidade Ao provisionar um cluster de nó único, você aceita que é mais provável que você experimente tempo de inatividade e interrupções em sua carga de trabalho e que os upgrades regulares do nó do trabalhador resultem em sua carga de trabalho ficando offline. Além disso, se um cluster for provisionado como um cluster de nó único, ele não poderá ser convertido posteriormente para um cluster padrão altamente disponível É possível incluir mais nós, mas as implementações padrão não aumentam no tamanho da réplica e o cluster não se torna altamente disponível Os clusters de nó único devem ser executados em um local do Satellite com Red Hat CoreOS(RHCOS)ativado. Os hosts de plano de controle em sua localização e o host designado ao cluster de nó único devem executar os sistemas operacionais RHEL 8 ou RHCOS. Suportado apenas para clusters do Satellite que executam a versão 4.11 ou mais recente. OpenShift Data Foundation não é suportado em clusters de nó único. Portworx não é suportado em clusters de nó único.

Recursos e operadores não suportados em Red Hat OpenShift on IBM Cloud

Os recursos e operadores a seguir não são suportados em Red Hat OpenShift on IBM Cloud.

Em vez de ajustar o desempenho do nó de trabalho com MachineConfig arquivos em Red Hat OpenShift, você pode modificar o host com um daemonset arquivo. Para obter mais informações, consulte Alterando o Calico MTU ou Ajustando o desempenho para nós de trabalho Red HatCoreOS.

  • AMQ Broker
  • AMQ Broker LTS
  • AMQ Interconnect
  • AMQ Online
  • AMQ Streams
  • Ansible Automation Platform Resource Operator
  • API Designer
  • Business Automation Operator
  • Camel K
  • Cost management Operator
  • Data Grid Operator
  • Gerenciador de dispositivos
  • File Integrity Operator
  • Fuse Console
  • Fuse Online
  • Gatekeeper Operator
  • JBoss EAP
  • JBoss Web Server
  • Armazenamento do gerenciador de volume lógico (LVM)
  • MachineConfigs
  • Metering and Cost Management SaaS Service
  • Serviço OpenShift Cloud Manager (OCM) SaaS
  • Proxy em todo o cluster do OpenShift
  • OpenShift Data Foundation: suportado por meio do complemento de cluster para clusters Classic e VPC ou por meio do Satellite modelo para clusters Satellite.
  • OpenShift O SDN e a maioria dos outros plug-ins de rede não são compatíveis
    • Calico é compatível com todas as versões do cluster.
    • O OVN é compatível com clusters VPC Red Hat OpenShift na versão 4.20 e posteriores, exclusivamente com nós de trabalho RHCOS.
    • Não atualize nem remova esses plug-ins de rede fora do processo normal de atualização do mestre do cluster.
  • Performance Add-on Operator
  • PTP Operator
  • Quay Operator
  • Red Hat OpenStack Integração da plataforma Kuryr
  • Red Hat Integration Operator
  • Service Registry Operator
  • Smart Gateway Operator
  • Operador de rede SR-IOV: suportado apenas em clusters do Satellite.
  • Telemeter and Insights Connected Experience
  • Configuração da máquina Windows: Nós do trabalhador com sistemas operacionais Windows não são suportados.
  • ImageContentSourcePolicy, ImageDigestMirrorSet e ImageTagMirrorSet não são compatíveis.