Componentes principais do Red Hat OpenShift

Revise os componentes a seguir no mestre gerenciado pela IBM de seu cluster Red Hat OpenShift on IBM Cloud.

Não é possível modificar esses componentes. A IBM gerencia os componentes e atualiza-os automaticamente durante as atualizações de correção do mestre.

No OpenShift Container Platform 4, muitos componentes são configurados por um operador correspondente para facilitar o gerenciamento. A tabela a seguir discute esses operadores e componentes em conjunto para se concentrar na principal funcionalidade que o componente fornece para o cluster.

Locatário único

O mestre e todos os componentes principais são dedicados apenas a você e não são compartilhados com outros clientes IBM.

Réplicas

Os componentes do mestre, incluindo o servidor de API e o armazenamento de dados etcd do Red Hat OpenShift, contam com três réplicas que, quando localizadas em uma área metropolitana multizona, são distribuídas entre as zonas para uma disponibilidade ainda mais alta.

cloud-controller-manager

O gerenciador do controlador de nuvem gerencia componentes específicos do provedor em nuvem, como o balanceador de carga do IBM Cloud.

cluster-health

O componente de funcionamento do cluster monitora o funcionamento do cluster e integra-se ao monitoramento do IBM Cloud e às métricas para o serviço.

cluster-policy-controller

O cluster-policy-controller mantém os recursos de política necessários para criar pods dentro do cluster.

cluster-version-operator

O cluster version operator (CVO) instala e atualiza outros operadores que são executados no cluster. Para obter mais informações, consulte o projeto “ GitHub ”.

control-plane-operator

O operador de plano de controle gerencia a instalação e a atualização dos componentes de plano de controle no mestre.

etcd, etcd-molecule, etcd-operator

etcd é um armazenamento de valores de chaves altamente disponível que armazena o estado de todos os recursos do Kubernetes de um cluster, como serviços, implementações e pods. Os dados no etcd são submetidos a backup a cada 8 horas para uma instância de armazenamento criptografada que a IBM gerencia.

kube-controller-manager, openshift-controller-manager

O controlador do Kubernetes monitora o estado dos objetos dentro do cluster, como o conjunto de réplicas de uma carga de trabalho. Quando o estado de um objeto mudar, por exemplo, se um pod em um conjunto de réplicas ficar inativo, o gerenciador do controlador iniciará a correção das ações para alcançar o estado necessário. O controlador do Red Hat OpenShift executa a mesma função para objetos que são específicos para a API do Red Hat OpenShift, como os projetos.

kube-scheduler

O agendador do Kubernetes monitora os pods recém-criados e decide onde implantá-los com base na capacidade, nas necessidades de desempenho, nas restrições de política, nas especificações de anti-afinidade e nos requisitos da carga de trabalho. Se não puder ser localizado nenhum nó do trabalhador que corresponda aos requisitos, o pod não será implementado no cluster.

manifests-bootstrapper

A tarefa “ manifests-boot-strapper ” configura o mestre com os certificados necessários para que ele se junte ao cluster como nó mestre.

oauth-openshift

O servidor OAuth integrado é configurado automaticamente para se integrar ao IBM Cloud Identity and Access Management (IAM). Não é possível incluir outros provedores de identidade suportados no cluster. Para obter mais informações sobre como se autenticar com o cluster via IAM, consulte Acessando os clusters Red Hat OpenShift.

openshift-apiserver, openshift-apiserver-operator, kube-apiserver

O servidor de API é o ponto de entrada principal para todas as solicitações de gerenciamento de cluster do nó do trabalhador para o mestre. O servidor da API valida e processa solicitações que mudam o estado de objetos do Kubernetes, como pods ou serviços, e objetos do Red Hat OpenShift, como projetos ou usuários. Em seguida, o servidor de API armazena esse estado no armazenamento de dados etcd.

konnectivity-server, konnectivity-operator

O servidor Konnectivity trabalha em conjunto com o agente Konnectivity para conectar com segurança o nó mestre ao nó de trabalho. Essa conexão suporta as chamadas apiserver proxy para seus pods e serviços, as chamadas oc exec, attach e logs para o kubelet e a mutação e validação de webhooks.

Controladores de admissão

Os controladores de admissão são implementados para recursos específicos nos clusters do Red Hat OpenShift on IBM Cloud. Com os controladores de admissão, é possível configurar políticas em seu cluster que determinam se uma ação específica no cluster é permitida ou não. Na política, é possível especificar condições quando um usuário não pode executar uma ação, mesmo que essa ação faça parte das permissões gerais que você designou ao usuário usando funções RBAC. Portanto, os controladores de admissão podem fornecer uma camada extra de segurança para o seu cluster antes que uma solicitação de API seja processada pelo servidor de API Red Hat OpenShift. Ao criar um cluster do Red Hat OpenShift, os seguintes controladores de admissão do Kubernetes são instalados automaticamente na ordem indicada no mestre do Red Hat OpenShift, ordem essa que não pode ser alterada pelo usuário:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultStorageClass
• ResourceQuota
• StorageObjectInUseProtection
• PersistentVolumeClaimResize
• Priority
• BuildByStrategy
• OriginPodNodeEnvironment
• PodNodeSelector
• ExternalIPRanger
• NodeRestriction
• SecurityContextConstraint
• SCCExecRestrictions
• PersistentVolumeLabel
• OwnerReferencesPermissionEnforcement
• PodTolerationRestriction
• openshift.io/JenkinsBootstrapper
• openshift.io/BuildConfigSecretInjector
• openshift.io/ImageLimitRange
• openshift.io/RestrictedEndpointsAdmission
• openshift.io/ImagePolicy
• openshift.io/IngressAdmission
• openshift.io/ClusterResourceQuota
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook

Você pode instalar seus próprios controladores de admissão no cluster ou escolher entre os controladores de admissão opcionais fornecidos pelo Red Hat OpenShift on IBM Cloud. Aplicação de medidas de segurança para imagens de contêiner: Instale Portieris para impedir a implantação de contêineres a partir de imagens não assinadas.

Se você instalou manualmente os controladores de admissão e não quiser mais usá-los, certifique-se de removê-los inteiramente. Se os controladores de admissão não forem completamente removidos, eles poderão bloquear todas as ações que você desejar executar no cluster.

Red Hat OpenShift componentes do nó de trabalho

Revise os componentes a seguir nos nós do trabalhador gerenciados pelo cliente de seu cluster Red Hat OpenShift on IBM Cloud.

Esses componentes são executados em seus nós do trabalhador porque você é capaz de usá-los com as cargas de trabalho que são implementadas em seu cluster. Por exemplo, seus apps podem usar um operador do OperatorHub que executa um contêiner por meio de uma imagem no registro interno. Você é responsável pelo seu uso desses componentes, mas a IBM fornece atualizações para eles nas atualizações de correção do nó do trabalhador que você escolhe aplicar.

No OpenShift Container Platform, muitos componentes são configurados por um operador responsável, para facilitar o gerenciamento. A tabela a seguir discute esses operadores e componentes em conjunto para se concentrar na principal funcionalidade que o componente fornece para o cluster.

Locatário único

Os nós do trabalhador e todos os componentes do nó do trabalhador são dedicados apenas a você e não são compartilhados com outros clientes IBM. No entanto, se você utilizar máquinas virtuais de nós de trabalho, o hardware subjacente poderá ser compartilhado com outros clientes do IBM, dependendo do nível de isolamento de hardware que você escolher.

Sistema Operacional

Para obter uma lista de sistemas operacionais suportados por versão do cluster, consulte as Informações da versão

Tempo de execução de contêiner do CRI-O

Seus nós de trabalho estão configurados com CRI-O como interface de tempo de execução do contêiner. Para obter mais informações, consulte Tempo de execução do contêiner.

Projetos

O Red Hat OpenShift organiza seus recursos em projetos, que são namespaces do Kubernetes com anotações, e inclui muitos mais componentes do que os clusters Kubernetes da comunidade para executar os recursos do Red Hat OpenShift como o catálogo. Os componentes selecionados de projetos são descritos nas linhas a seguir. Para obter mais informações, consulte Trabalho em um projeto.

calico-system, tigera-operator

O Calico gerencia políticas de rede para o seu cluster e inclui alguns componentes para gerenciar a conectividade de rede de contêineres, designação de endereço IP e controle de tráfego de rede. O operador Tigera instala e gerencia o ciclo de vida de componentes do Calico.

default

Este projeto será usado se você não especificar um projeto ou criar um projeto para os seus recursos de Kubernetes.

ibm-system

Esse projeto inclui a implementação ibm-cloud-provider-ip que funciona com keepalived para fornecer verificação de funcionamento e balanceamento de carga da Camada 4 para solicitações em pods do app.

kube-system

Esse projeto inclui muitos componentes que são usados para executar o Kubernetes no nó do trabalhador.

• ibm-master-proxy: O ibm-master-proxy é um conjunto de daemons que encaminha solicitações do nó do trabalhador para os endereços IP das réplicas do principal altamente disponíveis. Em clusters de zona única, o principal tem três réplicas em hosts separados. Para clusters que estão em uma zona com capacidade para várias zonas, o mestre tem três réplicas que são difundidas entre as zonas. Um balanceador de carga altamente disponível encaminha as solicitações para o nome de domínio principal para as réplicas principais.
• kubelet: O kubelet é um agente de nós do trabalhador que executa em cada nó do trabalhador e é responsável por monitorar o funcionamento de pods que são executados no nó do trabalhador e por assistir aos eventos que o servidor API envia. Com base nos eventos, o kubelet cria ou remove pods, assegura análises de vivacidade e prontidão e relata de volta o status dos pods para o servidor de API.
• vpn: O agente Konnectivity trabalha em conjunto com o servidor Konnectivity para conectar com segurança o nó mestre ao nó de trabalho. Essa conexão suporta chamadas apiserver proxy para seus pods e serviços e chamadas oc exec, attach e logs para o kubelet.
• Outros componentes: O projeto kube-system também inclui componentes para gerenciar recursos fornecidos pela IBM como plug-ins de armazenamento para armazenamento de arquivos e de blocos, balanceador de carga do aplicativo de ingresso (ALB) e keepalived.

openshift-cloud-credential-operator

O operador de credencial de nuvem gerencia um controlador para componentes do Red Hat OpenShift que solicitam credenciais do provedor de nuvem. O controlador assegura que somente as credenciais necessárias para a operação sejam usadas, e não quaisquer permissões elevadas como admin. Para obter mais informações, consulte o projeto “ GitHub ”.

openshift-cluster-node-tuning-operator

IBM gerencia o operador de ajuste de nós, que executa um conjunto de daemons em cada nó de trabalho do cluster para ajustar esses nós.

openshift-cluster-samples-operator

O operador de amostras gerencia determinados fluxos de imagens e modelos que vêm por padrão com o cluster do Red Hat OpenShift. É possível implementar esses modelos por meio da perspectiva do Desenvolvedor no console da web do Red Hat OpenShift.

openshift-cluster-storage-operator

O operador de armazenamento de cluster tem certeza de que uma classe de armazenamento padrão está configurada.

openshift-console, openshift-console-operator

O console da web do Red Hat OpenShift é uma interface baseada na web que você pode usar para gerenciar os recursos Red Hat OpenShift e Kubernetes que são executados no seu cluster. Também é possível usar o console para exibir um token oc login para autenticar em seu cluster por meio de uma CLI. Para obter mais informações, consulte Navegando no console do Red Hat OpenShift.

openshift-dns, openshift-dns-operator

O projeto DNS inclui os componentes para validar o tráfego de rede recebido com relação às regras iptables que são configuradas no nó do trabalhador e as solicitações de proxies que têm permissão para entrar ou deixar o cluster.

openshift-image-registry

Red Hat OpenShift fornece um servidor interno registro de imagens de contêineres que você pode usar para gerenciar e visualizar imagens localmente por meio do console. Alternativamente, é possível configurar o IBM Cloud Container Registry privado ou importar imagens do IBM Cloud Container Registry para o registro interno. O registro interno vem com um volume do tipo “ File Storage for Classic ” na sua conta da infraestrutura do IBM Cloud para armazenar as imagens do registro. O volume de armazenamento de arquivo é provisionado por meio da solicitação de volume persistente (PVC) image-registry-storage.

openshift-ingress, openshift-ingress-operator

Red Hat OpenShift utiliza rotas para expor diretamente o serviço de um aplicativo em um nome de host, de modo que clientes externos possam acessar o serviço. Para criar rotas, o cluster usa o operador do Ingress. Você também pode usar Ingress para expor apps externamente e customizar o roteamento. O Ingress consiste em três componentes: o operador de ingresso, o controlador de ingresso e os recursos de rota. O controlador de ingresso mapeia o serviço para o nome do host. Por padrão, o controlador de ingresso inclui duas réplicas. Certifique-se de que seu cluster tenha pelo menos dois nós do trabalhador para que o controlador de ingresso possa executar em hosts de cálculo separados para maior disponibilidade.

openshift-marketplace

O marketplace inclui o OperatorHub que vem por padrão com o cluster do Red Hat OpenShift. O OperatorHub inclui operadores do Red Hat e dos provedores de terceiros. Tenha em mente que esses operadores são fornecidos pela comunidade, podem não se integrar ao seu cluster e não são suportados pela IBM. É possível ativar operadores por meio do OperatorHub no console da web do Red Hat OpenShift.

openshift-monitoring

OpenShift Container Platform inclui uma pilha de monitoramento integrada para o seu cluster, que inclui métricas e recursos de gerenciamento de alertas. Para uma comparação da pilha de monitoramento integrada e outras opções como IBM Cloud Monitoring, consulte Entendendo as opções para criação de log e monitoramento.

openshift-multus

OpenShift Container Platform utiliza o plug-in de interface de rede de contêineres (CNI) do Multus para permitir várias redes de pods. No entanto, não é possível configurar o cluster para usar várias redes de pod. Os clusters Red Hat OpenShift on IBM Cloud suportam apenas Calico, que é configurado para o seu cluster por padrão. Se estiver ativado, o Service Mesh usará o plug-in Multus.

openshift-network-operator

O operador de rede do cluster(CNO) gerencia os componentes da rede do cluster configurados por padrão, como o plug-in do provedor de rede de pods CNI e o operador DNS.

openshift-operator-lifecycle-manager

O gerenciador do ciclo de vida dos operadores(OLM) gerencia o ciclo de vida de todos os operadores e do catálogo que são executados no cluster, incluindo os operadores dos componentes padrão e quaisquer operadores personalizados que você adicionar.

openshift-service-ca, openshift-service-ca-operator

O operador de autoridade de certificação (CA) executa a assinatura de certificado e injeta certificados em recursos do servidor de API e configmaps no cluster. Para obter mais informações, consulte o projeto “ GitHub ”.

Cluster com terminais em serviço de nuvem pública e privada

O diagrama a seguir mostra os componentes do seu cluster e como eles interagem quando os dois terminais em serviço de nuvem pública e privada estão ativados. Como ambos os terminais em serviço estão ativados, a VPC cria um balanceador de carga público para cada serviço para tráfego de entrada.

Cluster com terminal em serviço de nuvem privada apenas

O diagrama a seguir mostra os componentes do seu cluster e como eles interagem quando apenas o terminal em serviço de nuvem privada está ativado. Como apenas o terminal em serviço de nuvem privada está ativado, sua VPC cria um balanceador de carga privado para cada serviço para tráfego de entrada.

Componentes dos nós mestre e de trabalho do VPC

Mestrados e nós de trabalho incluem os mesmos componentes descritos na arquitetura de cluster clássica para clusters. Para obter mais informações sobre a OpenShift Container Platform arquitetura, consulte a Red Hat OpenShift documentação.

Master

Os componentes do mestre, incluindo o servidor de API e o etcd, possuem três réplicas e estão difundidos nas zonas para disponibilidade ainda maior. Os servidores mestres incluem os mesmos componentes descritos na arquitetura de cluster clássica para clusters. O mestre e todos os componentes principais são dedicados apenas a você e não são compartilhados com outros clientes IBM.

Nó do trabalhador

Com o Red Hat OpenShift on IBM Cloud, as máquinas virtuais gerenciadas pelo seu cluster são instâncias chamadas de nós do trabalhador. Essas máquinas virtuais de nós do trabalhador e todos os componentes do nó do trabalhador são dedicados apenas a você e não são compartilhados com outros clientes IBM. No entanto, o hardware subjacente é compartilhado com outros clientes IBM. Você gerencia os nós do trabalhador por meio das ferramentas de automação que são fornecidas por Red Hat OpenShift on IBM Cloud, como a API, a CLI ou o console. Ao contrário dos clusters clássicos, você não vê nós do trabalhador de computação de VPC no portal de infraestrutura ou no projeto de infraestrutura separado, mas gerencia toda a atividade de manutenção e faturamento para os nós do trabalhador por meio do IBM Cloud Kubernetes Service.

Os nós de trabalho incluem os mesmos componentes descritos na arquitetura de cluster clássica.

Ao executar oc get nodes, é possível notar que as FUNÇÕES de seus nós do trabalhador estão marcadas como ambas, master,worker. Esses nós são nós do trabalhador na IBM Cloud, e não incluem os componentes principais que são gerenciados pela IBM. Em vez disso, esses nós são marcados como master porque executam os componentes do OpenShift Container Platform que são necessários para configurar e gerenciar recursos padrão dentro do cluster, como o OperatorHub e o registro interno.

Redes de cluster

Seus nós do trabalhador são criados em uma sub-rede da VPC na zona especificada. A comunicação entre os nós principal e do trabalhador é sobre a rede privada. Se você criar um cluster com os terminais em serviço de nuvem pública e privada ativados, os usuários externos autenticados poderão se comunicar com o principal sobre a rede pública, como para executar comandos oc. Se você criar um cluster com apenas os terminais em serviço de nuvem privada ativados, os usuários externos autenticados poderão se comunicar com o principal sobre a rede privada apenas. É possível configurar o cluster para se comunicar com recursos em redes no local, em outras VPCs ou na infraestrutura clássica ao definir uma VPN da VPC, um IBM Cloud Direct Link ou um IBM Cloud Transit Gateway na rede privada.

Redes de aplicativo

Os balanceadores de carga da Nuvem Privada Virtual (VPC) são criados automaticamente na sua VPC, fora do cluster, para quaisquer serviços de rede que você criar no seu cluster. Por exemplo, um balanceador de carga de VPC expõe os serviços do roteador em seu cluster por padrão. Ou é possível criar um serviço LoadBalancer do Kubernetes para seus apps, e um balanceador de carga de VPC é gerado automaticamente. Os balanceadores de carga de VPC são solicitações multizona e de rota para o seu app por meio das portas do nó privado que são abertas automaticamente em seus nós do trabalhador. Se os terminais em serviço de nuvem pública e privada estiverem ativados, os roteadores e os balanceadores de carga de VPC serão criados como públicos por padrão. Se apenas o terminal em serviço de nuvem privada estiver ativado, os roteadores e os balanceadores de carga de VPC serão criados como privados por padrão. Para obter mais informações, consulte Público ou Rede de apps privada para clusters de VPC. O Calico é usado como a malha de políticas de rede do cluster.

Storage

É possível configurar o IBM Cloud Object Storage e o Cloud Databases apenas.