Perguntas frequentes para IBM Cloud® Kubernetes Service
Consulte as perguntas frequentes ( Perguntas frequentes ) sobre como usar o site IBM Cloud® Kubernetes Service.
O que é Kubernetes?
O Kubernetes é uma plataforma de software livre para gerenciar cargas de trabalho e serviços conteinerizados em múltiplos hosts, que oferece ferramentas de gerenciamento para implementar, automatizar, monitorar e escalar apps conteinerizados com intervenção manual mínima ou até nenhuma. Todos os contêineres que compõem seu microsserviço são agrupados em pods, uma unidade lógica para assegurar fácil gerenciamento e descoberta. Esses pods são executados em hosts de cálculo que são gerenciados em um cluster Kubernetes que é móvel, extensível e com capacidade de recuperação automática em caso de falhas.
Para obter mais informações sobre Kubernetes, consulte a Documentação do Kubernetes.
Como criar um cluster do IBM Cloud Kubernetes Service ?
Para criar um cluster IBM Cloud Kubernetes Service, primeiro decida se deseja seguir um tutorial para uma configuração básica de cluster ou projetar seu próprio ambiente em cluster.
- Eu quero seguir um tutorial
- Comece revisando o documento Introdução, em seguida escolha um dos tutoriais disponíveis.
- Desejo projetar meu próprio ambiente em cluster
- Comece revisando o documento Introdução e, em seguida, crie sua estratégia de ambiente em cluster
Como o IBM Cloud Kubernetes Service funciona?
Com o IBM Cloud Kubernetes Service, é possível criar seu próprio cluster do Kubernetes para implementar e gerenciar apps conteinerizados no IBM Cloud. Seus apps conteinerizados são hospedados em hosts de cálculo da infraestrutura da IBM Cloud que são chamados de nós do trabalhador. Você pode optar por provisionar seus hosts de computação como máquinas virtuais com recursos compartilhados ou dedicados, ou como máquinas bare metal que podem ser otimizadas para o uso de GPUs e armazenamento definido por software (SDS). Os nós do trabalhador são controlados por um mestre do Kubernetes altamente disponível que é configurado, monitorado e gerenciado pela IBM. É possível usar a API ou CLI do IBM Cloud Kubernetes Service para trabalhar com seus recursos de infraestrutura do cluster e a API ou a CLI do Kubernetes para gerenciar suas implementações e serviços.
Para obter mais informações sobre como os recursos de cluster são configurados, consulte a Arquitetura de serviço. Para localizar uma lista de recursos e benefícios, consulte Benefícios e ofertas de serviços.
Por que eu deveria usar IBM Cloud Kubernetes Service?
O IBM Cloud Kubernetes Service é uma oferta de Kubernetes gerenciada que oferece ferramentas poderosas, uma experiência de usuário intuitiva e segurança integrada para entrega rápida de apps que podem ser ligados aos serviços de nuvem relacionados ao IBM Watson®, IA, IoT, DevOps, segurança e análise de dados. Como provedor certificado do Kubernetes, o IBM Cloud Kubernetes Service oferece suporte a agendamento inteligente, autocorreção, escalonamento horizontal, descoberta de serviços e balanceamento de carga, implantações e reversões automatizadas, além de gerenciamento de segredos e configurações. O serviço também tem recursos avançados de gerenciamento de cluster simplificado, políticas de segurança e isolamento de contêiner, a capacidade de projetar seu próprio cluster e ferramentas operacionais integradas para consistência na implementação.
Para obter uma visão geral detalhada de recursos e benefícios, consulte Benefícios de uso do serviço.
Quais plataformas de contêiner estão disponíveis para meu cluster?
Com a IBM Cloud, é possível criar clusters para suas cargas de trabalho conteinerizadas em duas plataformas de gerenciamento de contêiner diferentes: a versão IBM do Kubernetes da comunidade e do Red Hat OpenShift on IBM Cloud. A plataforma de contêiner que você seleciona é instalada no cluster mestre e nos nós do trabalhador. Depois é possível atualizar a versão, mas não retroceder para uma versão anterior ou mudar para uma plataforma de contêiner diferente. Para usar diversas plataformas de contêiner, crie um cluster separado para cada uma delas.
Para obter mais informações, consulte a Comparação entre Red Hat OpenShift e clusters Kubernetes da comunidade.
- Kubernetes
- Kubernetes é uma plataforma de orquestração de contêiner de software livre, de nível de produção, que você pode ser usada para automatizar, escalar e gerenciar os apps conteinerizados que são executados em um sistema operacional Ubuntu. Com a versão do IBM Cloud Kubernetes Service, você tem acesso aos recursos da API do Kubernetes da comunidade que são considerados beta ou mais recentes pela comunidade. Os recursos alpha do Kubernetes, que estão sujeitos a mudança, geralmente não são ativados por padrão. Com Kubernetes, é possível combinar vários recursos, como segredos, implementações e serviços para criar e gerenciar com segurança os aplicativos altamente disponíveis e conteinerizados.
- Red Hat OpenShift
- Red Hat OpenShift on IBM Cloud é uma plataforma baseada em Kubernetes, projetada especialmente para acelerar seus processos de entrega de aplicativos em contêineres que rodam no sistema operacional Red Hat Enterprise Linux. É possível orquestrar e escalar suas cargas de trabalho existentes do Red Hat OpenShift em nuvens no local e fora do local para uma solução híbrida móvel que funciona da mesma forma em cenários de multinuvem. Para começar, experimente o tutorial do Red Hat OpenShift on IBM Cloud.
O serviço vem com um mestre do Kubernetes gerenciado e nós do trabalhador?
Cada cluster no IBM Cloud Kubernetes Service é controlado por um mestre do Kubernetes dedicado que é gerenciado pela IBM em uma conta de infraestrutura do IBM Cloud de propriedade da IBM. O mestre do Kubernetes, incluindo todos os componentes principais, recursos de cálculo, de rede e de armazenamento, é monitorado continuamente pelos IBM Site Reliability Engineers (SREs). Os SREs aplicam os padrões de segurança mais recentes, detectam e corrigem atividades maliciosas e trabalham para assegurar a confiabilidade e disponibilidade do IBM Cloud Kubernetes Service. Os complementos, como Fluentd para criação de log, que são instalados automaticamente quando você provisiona o cluster são atualizados automaticamente pela IBM. No entanto, é possível optar por desativar atualizações automáticas para alguns complementos e atualizá-las manualmente separadamente dos nós principal e do trabalhador. Para obter mais informações, consulte Atualizando complementos de cluster.
Periodicamente, o Kubernetes libera atualizações principais, secundárias ou de correção. Essas atualizações podem afetar a versão do servidor da API do Kubernetes ou outros componentes em seu mestre do Kubernetes. A IBM atualiza automaticamente a versão de correção, mas deve-se atualizar as versões principais e secundárias. Para obter mais informações, consulte Atualizando o mestre.
Os nós do trabalhador em clusters padrão são provisionados para a sua conta de infraestrutura do IBM Cloud. Os nós do trabalhador são dedicados à sua conta e você é responsável por solicitar atualizações oportunas aos nós do trabalhador para assegurar que o S.O. do nó do trabalhador e os componentes do IBM Cloud Kubernetes Service apliquem as atualizações e correções de segurança mais recentes. As atualizações e correções de segurança são disponibilizadas pelo IBM Site Reliability Engineers (SREs) que monitora continuamente a imagem do Linux que está instalada em seus nós do trabalhador para detectar vulnerabilidades e problemas de conformidade de segurança. Para obter mais informações, consulte Atualizando nós do trabalhador.
Quais tipos de cargas de trabalho posso mover para o IBM Cloud Kubernetes Service?
Para ver exemplos dos tipos de cargas de trabalho que os usuários costumam migrar para os diversos tipos de nuvem, consulte “Migrando suas cargas de trabalho para IBM Cloud ”. Você também pode escolher uma abordagem híbrida na qual possui clusters que são executados em ambos os ambientes.
Posso automatizar minhas implementações de infraestrutura?
Caso deseje executar seu app em diversos clusters, em ambientes públicos e privados ou, até mesmo, em diversos provedores em nuvem, é possível que você esteja se perguntando como fazer sua estratégia de implementação funcionar nesses ambientes.
É possível usar a ferramenta de software livre Terraform para automatizar o fornecimento da infraestrutura do IBM Cloud, incluindo clusters Kubernetes. Siga este tutorial para criar Kubernetes e clusters OpenShift únicos e multizona. Após criar um cluster, crie também o escalador automático do IBM Cloud Kubernetes Service para que o conjunto de trabalhadores aumente e reduza a escala dos nós do trabalhador em resposta às solicitações de recursos de sua carga de trabalho.
Que tipo de apps podem ser executados? É possível mover apps existentes ou preciso desenvolver novos apps?
Seu app conteinerizado deve ser capaz de executar em um dos sistemas operacionais suportados para a versão do cluster. Também é recomendado considerar a capacidade de seu app de ser stateful. Para obter mais informações sobre os tipos de apps que podem ser executados no IBM Cloud Kubernetes Service, consulte Planejando implementações de apps.
Se você já tiver um app, será possível migrá-lo para o IBM Cloud Kubernetes Service. Para desenvolver um novo app, confira as diretrizes para desenvolvimento de apps stateless nativos de nuvem.
E quanto aos apps serverless?
É possível executar tarefas e apps serverless através do serviço IBM Cloud Code Engine. O Code Engine também pode construir suas imagens para você. O Code Engine foi projetado para que não seja preciso interagir com a tecnologia subjacente na qual ele é construído. No entanto, se você tiver o conjunto de ferramentas existente que é baseado em Kubernetes ou Knative, será possível ainda usá-lo com o Code Engine. Para obter mais informações, consulte Usando o Kubernetes para interagir com seu aplicativo.
Quais qualificações devo ter antes de mover meus apps para um cluster?
O Kubernetes é projetado para fornecer recursos para duas personas principais, o administrador do cluster e o desenvolvedor de app. Cada persona usa diferentes qualificações técnicas para executar e implementar com êxito apps em um cluster.
- Quais são as principais tarefas e os conhecimentos técnicos de um administrador de cluster?
- Como um administrador de cluster, você é responsável por configurar, operar, proteger e gerenciar a infraestrutura do IBM Cloud de seu cluster. As tarefas típicas incluem:
- Dimensionar o cluster para fornecer capacidade suficiente para suas cargas de trabalho.
- Projetar um cluster para atender aos padrões de alta disponibilidade, recuperação de desastre e conformidade de sua empresa.
- Proteger o cluster configurando permissões de usuário e limitando ações dentro do cluster para proteger seus recursos de cálculo, sua rede e dados.
- Planejar e gerenciar a comunicação de rede entre os componentes de infraestrutura para assegurar a segurança de rede, segmentação e conformidade.
- Planejar opções de armazenamento persistente para atender aos requisitos de residência de dados e de proteção de dados.
A persona do administrador do cluster deve ter um amplo conhecimento que inclua cálculo, rede, armazenamento, segurança e conformidade. Em uma empresa típica, esse conhecimento é difundido entre múltiplos especialistas, como Engenheiros de Sistemas, Administradores do Sistema, Engenheiros de Rede, Arquitetos de Rede, Gerentes de TI ou Especialistas de Segurança e Conformidade. Considere designar a função de administrador do cluster a múltiplas pessoas em sua empresa para que você tenha o conhecimento necessário para operar com êxito seu cluster.
- Quais são as principais tarefas e habilidades técnicas de um desenvolvedor de aplicativos?
- Como um desenvolvedor, você projeta, cria, protege, implementa, testa, executa e monitora apps nativos de nuvem, conteinerizados em um cluster Kubernetes. Para criar e executar esses apps, deve-se estar familiarizado com o conceito de microsserviços, as diretrizes de Twelve-Factor App, os Princípios de docker e conteinerização e as Opções de implementação do Kubernetes disponíveis.
O Kubernetes e o IBM Cloud Kubernetes Service fornecem múltiplas opções de como expor um app e manter um app privado, incluir armazenamento persistente, integrar outros serviços e como é possível proteger suas cargas de trabalho e proteger dados sensíveis. Antes de migrar seu aplicativo para um cluster no IBM Cloud Kubernetes Service, verifique se é possível executá-lo como um aplicativo em contêiner no sistema operacional compatível e se Kubernetes e IBM Cloud Kubernetes Service oferecem os recursos necessários para sua carga de trabalho.
- Os administradores de cluster e os desenvolvedores interagem entre si?
- Sim. Os administradores e os desenvolvedores de cluster devem interagir com frequência para que os administradores de cluster entendam os requisitos de carga de trabalho para fornecer essa capacidade no cluster e para que os desenvolvedores saibam sobre limitações, integrações e princípios de segurança disponíveis que devem considerar em seu processo de desenvolvimento de app.
Quais opções eu tenho para proteger meu cluster?
É possível usar recursos de segurança integrados no IBM Cloud Kubernetes Service para proteger os componentes em seu cluster, seus dados e implementações de app para assegurar a conformidade de segurança e a integridade de dados. Use esses recursos para proteger seu servidor de API do Kubernetes, armazenamento de dados etcd, nó do trabalhador, rede, armazenamento, imagens e implementações contra ataques maliciosos. Também é possível alavancar a criação de log integrada e as ferramentas de monitoramento para detectar ataques maliciosos e padrões de uso suspeitos.
Para obter mais informações sobre os componentes do seu cluster e como é possível atender às normas de segurança de cada componente, consulte Segurança para o IBM Cloud Kubernetes Service.
Que políticas de acesso eu dou aos meus usuários de cluster?
O IBM Cloud Kubernetes Service usa o Cloud Identity and Access Management (IAM) para conceder acesso a recursos de cluster por meio de funções de acesso à plataforma do IAM e de políticas de controle de acesso baseado na função (RBAC) do Kubernetes por meio de funções de acesso ao serviço IAM. Para obter mais informações sobre os tipos de políticas de acesso, consulte “Escolha a política de acesso e a função corretas para seus usuários ”.
Quais permissões o usuário que configura a chave da API precisa ter? Como faço para conceder essas permissões ao usuário?
No mínimo, as funções Administradores ou Gerenciamento de conformidade têm permissões para criar um cluster. No entanto, você pode precisar de permissões adicionais para outros serviços e integrações que você usa em seu cluster. Para obter mais informações, consulte Permissões para criar um cluster.
Para verificar as permissões de um usuário, revise as políticas de acesso e os grupos de acesso do usuário no console da IBM Cloud ou use o comando ibmcloud iam user-policies <user>.
Se a chave da API estiver vinculada a um único usuário, como isso afeta os demais usuários do cluster na região e no grupo de recursos?
Outros usuários dentro da região e do grupo de recursos da conta compartilham a chave de API para acessar a infraestrutura e outros serviços com clusters IBM Cloud Kubernetes Service. Quando os usuários efetuam login na conta do IBM Cloud, um token do IBM Cloud IAM que é baseado na chave de API é gerado para a sessão da CLI e permite que os comandos relacionados à infraestrutura sejam executados em um cluster.
O que acontece se o usuário que configurou a chave de API para uma região e um grupo de recursos deixar a empresa?
Se o usuário estiver saindo de sua organização, o proprietário da conta do IBM Cloud poderá remover as permissões desse usuário. No entanto, antes de remover as permissões de acesso específicas de um usuário ou remover um usuário de sua conta completamente, deve-se reconfigurar a chave de API com as credenciais de infraestrutura de outro usuário. Caso contrário, os outros usuários na conta poderão perder o acesso ao portal de infraestrutura da IBM Cloud e os comandos relacionados a infraestrutura podem falhar. Para obter mais informações, consulte Removendo permissões do usuário.
Como posso proteger meu cluster caso minha chave de API seja comprometida?
Se uma chave de API que é configurada para uma região e grupo de recursos no cluster estiver comprometida, exclua-a para que nenhuma chamada adicional possa ser feita usando a chave de API como autenticação. Para obter mais informações sobre como proteger o acesso ao servidor de API do Kubernetes, consulte o tópico de segurança Servidor de API do Kubernetes e etcd.
Como faço para girar a chave de API do cluster se houver um vazamento?
Para obter instruções sobre como alternar sua chave de API, consulte Como faço para alternar a chave de API do cluster se houver um vazamento?
Onde é possível localizar uma lista de boletins de segurança que afetam meu cluster?
Se as vulnerabilidades forem localizadas no Kubernetes, o Kubernetes liberará CVEs em boletins de segurança para informar aos usuários e para descrever as ações que os usuários devem tomar para corrigir a vulnerabilidade. Boletins de segurança do Kubernetes que afetam os usuários do IBM Cloud Kubernetes Service ou a plataforma do IBM Cloud são publicados no Boletim de segurança do IBM Cloud.
Alguns CVEs requerem a atualização de correção mais recente para uma versão que pode ser instalada como parte do processo de atualização de cluster regular no IBM Cloud Kubernetes Service. Certifique-se de aplicar as correções de segurança no tempo para proteger seu cluster de ataques maliciosos. Para obter mais informações sobre o que está incluído em um patch de segurança, consulte o registro de alterações da versão.
O serviço oferece suporte para bare metal e GPU?
Certos sabores de nó do trabalhador VPC oferecem suporte a GPU. Para obter mais informações, consulte os Sabores VPC.
Sim, é possível provisionar seu nó do trabalhador como um servidor bare metal físico de único locatário. Os servidores bare metal vêm com benefícios de alto desempenho para cargas de trabalho, como dados, GPU e IA. Além disso, todos os recursos de hardware são dedicados a suas cargas de trabalho, para que você não tenha que se preocupar com "vizinhos barulhentos".
Para obter mais informações sobre os tipos de bare metal disponíveis e como o bare metal difere das máquinas virtuais, consulte o guia de planejamento.
Qual é o tamanho mínimo de cluster que posso criar?
Observe que a execução de um cluster mínimo não atende ao contrato de nível de serviço (SLA) para receber suporte. Além disso, tenha em mente que alguns serviços, como Ingress, requerem configurações de nó do trabalhador altamente disponíveis. Talvez você não consiga executar esses serviços ou seus apps em clusters com apenas dois nós em um conjunto de trabalhadores. Para obter mais informações, consulte Planejando seu cluster para alta disponibilidade.
- Clusters clássicos ou VPC
- Os clusters sempre devem ter pelo menos um nó do trabalhador. Observe que não é possível ter um cluster com 0 nós de trabalho, e também não é possível desligar ou suspender o faturamento dos seus nós de trabalho.
- Clusters Satellite
- Os clusters podem ser criados usando a topologia de réplica única, o que significa apenas um nó do trabalhador Observe que se você criar um cluster do Satellite usando a topologia de réplica única, não será possível incluir nós do trabalhador posteriormente.
Quais versões o serviço suporta?
O IBM Cloud Kubernetes Service suporta simultaneamente múltiplas versões do Kubernetes. Quando uma nova versão (n) é lançada, as versões até duas versões anteriores ( n-2 ) continuam sendo suportadas. As versões com mais de 2 atrás do mais recente (n-3) são descontinuadas primeiro e depois não suportadas.
Para obter mais informações sobre as versões compatíveis e as ações de atualização necessárias para migrar de uma versão para outra, consulte as informações sobre versões do Kubernetes.
Quais sistemas operacionais do nó do trabalhador faz o suporte de serviço?
Para obter uma lista de sistemas operados pelo nó do trabalhador suportados por versão do cluster, consulte as informações da versão doKubernetes
Onde o serviço está disponível?
IBM Cloud Kubernetes Service está disponível no mundo todo. É possível criar clusters em todas as regiões do IBM Cloud Kubernetes Service compatíveis.
Para obter mais informações sobre regiões suportadas, consulte Locais.
O serviço está altamente disponível?
Sim. Por padrão, o IBM Cloud Kubernetes Service configura muitos componentes, como o cluster mestre com réplicas, antiafinidade e outras opções para aumentar a alta disponibilidade (HA) do serviço. É possível aumentar a redundância e a tolerância a falhas de seus nós do trabalhador do cluster, armazenamento, rede e cargas de trabalho, configurando-os em uma arquitetura altamente disponível. Para obter uma visão geral da configuração padrão e de suas opções para aumentar a HA, consulte Criando uma estratégia de cluster altamente disponível.
Para obter os termos de acordo de nível de serviço de HA mais recentes, consulte os termos de serviço da IBM Cloud. Geralmente, os termos de disponibilidade do SLA requerem que, ao configurar os recursos de infraestrutura em uma arquitetura de HA, eles sejam distribuídos uniformemente em três zonas de disponibilidade diferentes. Por exemplo, para receber cobertura completa de HA sob os termos do SLA, deve-se configurar um cluster multizona com um total de pelo menos seis nós do trabalhador, sendo dois nós do trabalhador por zona distribuídos uniformemente em três zonas.
Como funcionam os clusters multizonas?
Como está configurado o meu conjunto principal do IBM Cloud Kubernetes Service?
Ao criar um cluster em um local multizona, um principal altamente disponível é implementado automaticamente e três réplicas são distribuídas pelas zonas metropolitanas. Por exemplo, se o cluster estiver nas zonas dal10, dal12 ou dal13, as réplicas do mestre serão difundidas em cada zona na área metropolitana multizona de Dallas.
Preciso fazer alguma coisa para que o mestre consiga se comunicar com os trabalhadores em diferentes zonas?
Se você criou um cluster multizona VPC, as sub-redes em cada zona serão configuradas automaticamente com listas de controle de acesso (ACLs) que permitem a comunicação entre o mestre e os nós do trabalhador nas zonas. Em clusters clássicos,
caso haja várias VLANs para o cluster, várias sub-redes na mesma VLAN ou um cluster clássico de várias zonas, deve-se ativar uma Virtual Router Function (VRF) para a conta de infraestrutura do IBM Cloud para que os nós do trabalhador possam se comunicar entre si na rede privada. Para ativar o VRF, consulte Ativando o VRF.
Para verificar se um VRF já está ativado, use o comando ibmcloud account show. Se não puder ou não quiser ativar a VRF, ative a Ampliação de VLAN. Para realizar
essa ação, você precisa da permissão de infraestrutura “ Rede > Gerenciar a extensão de VLANs da rede ” ou pode solicitar ao proprietário da conta que a habilite. Para verificar se o spanning de VLAN já está habilitado,
use o comando ibmcloud ks vlan spanning get --region
.
Posso converter meu cluster de zona única em um cluster multizona?
Para converter um cluster de zona única em um cluster de várias zonas, o cluster deve ser configurado em um local que tenha mais de uma zona de disponibilidade.
- Os clusters VPC só podem ser configurados em regiões com várias zonas e, por isso, sempre podem ser convertidos de um cluster de zona única para um cluster com várias zonas. Para obter mais informações, consulte Adicionar nós de trabalho a clusters VPC.
- Os clusters clássicos que são configurados em data centers com apenas uma zona não podem ser convertidos em um cluster de várias zonas. Para obter mais informações, consulte Adicionar nós de trabalho a clusters Classic.
E se eu quiser configurar vários clusters em diferentes regiões?
É possível configurar diversos clusters em diferentes regiões de uma localização geográfica (como o Sul dos EUA e o Leste dos EUA) ou entre as localizações geográficas (como o Sul dos EUA e a Central da UE). Ambas as configurações oferecem o mesmo nível de disponibilidade para seu app, mas também incluem a complexidade quando se trata de compartilhamento de dados e replicação de dados. Para a maioria dos casos, permanecer dentro da mesma localização geográfica é suficiente. Mas se você tiver usuários em todo o mundo, talvez seja melhor configurar um cluster no qual os usuários estejam para que esses usuários não enfrentem longos períodos de espera ao enviarem uma solicitação para o app.
Quais são as opções disponíveis para distribuir cargas de trabalho entre vários clusters?
Para balancear a carga de cargas de trabalho em diversos clusters, deve-se disponibilizar os apps na rede pública usando os Balanceadores de carga do aplicativo (ALBs) ou os Balanceadores de carga de rede (NLBs). Os ALBs e os NLBs recebem um endereço IP público que pode ser usado para acessar seus apps.
Para balancear a carga de cargas de trabalho em seus apps, inclua os endereços IP públicos de seus ALBs e NLBs em um balanceador de carga global do CIS ou em seu próprio balanceador de carga global.
E se eu quiser distribuir a carga de trabalho na rede privada?
A IBM Cloud não oferece um serviço global de balanceador de carga na rede privada. No entanto, é possível conectar seu cluster a um balanceador de carga privado hospedado em sua rede local usando uma das opções de VPN suportadas. Certifique-se de expor seus apps na rede privada usando os Balanceadores de carga do aplicativo (ALBs) ou os Balanceadores de carga de rede (NLBs) e use o endereço IP privado em suas configurações de VPN para conectar seu app à sua rede local.
O mestre e os nós do trabalhador são altamente disponíveis?
A arquitetura e a infraestrutura do IBM Cloud Kubernetes Service são projetadas para assegurar a confiabilidade, a latência de processamento baixo e um tempo de atividade máximo do serviço. Por padrão, cada cluster no IBM Cloud Kubernetes Service é configurado com diversas instâncias de principal do Kubernetes para garantir a disponibilidade e a acessibilidade de seus recursos de cluster, mesmo se uma ou mais instâncias de seu principal do Kubernetes estiverem indisponíveis.
É possível tornar seu cluster ainda mais altamente disponível e proteger seu app de um tempo de inatividade, difundindo suas cargas de trabalho em diversos nós do trabalhador em diversas zonas de uma região. Essa configuração é chamada de cluster multizona e garante que seu aplicativo permaneça acessível, mesmo que um nó de trabalho ou uma zona inteira esteja indisponível.
Para se proteger contra uma falha em toda uma região, crie vários clusters e distribua-os por várias regiões d IBM Cloud. Ao configurar um balanceador de carga de rede (NLB) para seus clusters, é possível obter o balanceamento de carga entre regiões e a rede entre regiões para seus clusters.
Se você tiver dados que devem estar disponíveis, mesmo que ocorra uma indisponibilidade, certifique-se de armazenar seus dados no armazenamento persistente.
Para obter mais informações sobre como obter alta disponibilidade para seu cluster, veja Alta disponibilidade para o IBM Cloud Kubernetes Service.
Meus aplicativos se distribuem automaticamente entre as zonas?
Depende de como o app é configurado. Consulte Planejando implementações altamente disponíveis e Planejando o armazenamento persistente altamente disponível.
Os nós de trabalho estão criptografados?
O disco secundário do nó do trabalhador é criptografado. Para obter mais informações, consulte Visão geral da criptografia de cluster. Depois de criar um conjunto de trabalhadores, talvez
você note que o tipo do nó do trabalhador tem .encrypted no nome, como b3c.4x16.encrypted.
Quais normas de conformidade o serviço atende?
O IBM Cloud é construído seguindo muitos dados, finanças, saúde, seguro, privacidade, segurança, tecnologia e outros padrões de conformidade internacional. Para obter mais informações, consulte Conformidade do IBM Cloud.
Para visualizar os requisitos detalhados do sistema, é possível executar um relatório de compatibilidade do produto de software para o IBM Cloud Kubernetes Service. Observe que a conformidade depende do provedor de infraestrutura subjacente para os nós do trabalhador do cluster, rede e recursos de armazenamento.
Infraestrutura clássica: O serviço “ IBM Cloud Kubernetes Service ” implementa controles compatíveis com os seguintes padrões de segurança:
- EU-US Privacy Shield e Swiss-US Privacy Shield Framework
- Health Insurance Portability and Accountability Act (HIPAA)
- Normas de Controle da Organização de Serviços (SOC 1 Tipo 2, SOC 2 Tipo 2)
- International Standard on Assurance Engagements 3402 (ISAE 3402), Assurance Reports on Controls at a Service Organization
- International Organization for Standardization (ISO 27001, ISO 27017, ISO 27018)
- Payment Card Industry Data Security Standard (PCI DSS)
Infraestrutura de VPC: O serviço “ IBM Cloud Kubernetes Service ” implementa controles compatíveis com os seguintes padrões de segurança:
- EU-US Privacy Shield e Swiss-US Privacy Shield Framework
- Health Insurance Portability and Accountability Act (HIPAA)
- International Standard on Assurance Engagements 3402 (ISAE 3402), Assurance Reports on Controls at a Service Organization
É possível usar outros serviços do IBM Cloud com o meu cluster
É possível incluir serviços de plataforma e infraestrutura do IBM Cloud, bem como serviços de fornecedores de terceiros para seu cluster do IBM Cloud Kubernetes Service a fim de ativar a automação, melhorar a segurança ou aprimorar os recursos de monitoramento e criação de log no cluster.
Para obter uma lista de serviços suportados, consulte Integrando serviços.
Como faço para instalar um servidor de gerenciamento de aplicativos ( Cloud Pak ) no meu cluster?
Os Cloud Paks são integrados ao catálogo da IBM Cloud para que seja possível configurar e instalar rapidamente todos os componentes do Cloud Pak em um cluster Red Hat OpenShift novo ou existente. Ao instalar o Cloud Pak, o Cloud Pak é configurado com o Schematics e um espaço de trabalho Schematics é criado para você. É possível usar a área de trabalho posteriormente para acessar informações sobre sua instalação do Cloud Pak. Você acessa seus serviços do Cloud Pak por meio da URL do Cloud Pak. Para obter mais informações, consulte o ' documentação Cloud Pak.
É possível usar a autorização do Red Hat OpenShift que vem com o meu Cloud Pak para o meu cluster?
Sim, se o seu Cloud Pak incluir uma autorização para executar determinados tipos de nó do trabalhador que estão instalados com a OpenShift Container Platform. Para ver seus direitos, faça o check-in IBM Passport Advantage. Note que o seu ID do IBM Cloud deve corresponder ao seu ID do IBM Passport Advantage.
É possível criar o cluster ou o conjunto de workers dentro de um cluster existente com o direito “ Cloud Pak ” no console ou usando a opção “ --entitlement ocp_entitled ” no ibmcloud ks cluster create classic ou ibmcloud ks worker-pool create classic comandos da CLI. Certifique-se de especificar o número correto e o tipo de nós do
trabalhador que você está autorizado a usar.
Não exceda a sua autorização. Lembre-se de que as suas autorizações do OpenShift Container Platform podem ser usadas com outros provedores em nuvem ou em outros ambientes. Para evitar problemas de cobrança posteriormente, certifique-se de usar apenas o que você tem direito a usar. Por exemplo, talvez você tenha uma autorização das licenças OCP para dois nós do trabalhador de quatro CPUs e 16 GB de memória e crie esse conjunto de trabalhadores com dois nós do trabalhador de quatro CPUs e 16 GB de memória. Você usou toda a sua titularidade e não pode usar a mesma titularidade para outros conjuntos de trabalhadores, provedores de nuvem ou ambientes.
Posso instalar vários Cloud Paks no mesmo cluster do Red Hat OpenShift on IBM Cloud ?
Sim, mas pode ser necessário incluir mais nós do trabalhador para que cada Cloud Pak tenha recursos de cálculo suficientes para executar Além disso, é possível instalar apenas uma instância do mesmo Cloud Pak por cluster, como Cloud Pak for Data; ou várias instâncias para diferentes projetos no mesmo cluster, como o Cloud Pak for Automation Para obter informações de dimensionamento, consulte a documentação doCloud Pak
O que está incluído em um Cloud Pak?
Os Cloud Paks são softwares empacotados, licenciados e conteinerizados que são otimizados para trabalhar em conjunto para casos de uso corporativos, incluindo implementação consistente, controle de acesso e faturamento. Você pode utilizar partes dos Cloud Paks de forma flexível, sempre que precisar, escolhendo a combinação adequada de núcleos de processador virtuais do software para atender às suas cargas de trabalho. Também é possível mudar a combinação de núcleos de processador virtual conforme suas cargas de trabalho evoluem.
Dependendo do Cloud Pak, você obtém um software livre e licenciado pela IBM empacotado junto em uma experiência de gerenciamento unificada com recursos de criação de log, monitoramento, segurança e acesso.
- IBM produtos: Os Cloud Paks ampliam o software e o middleware licenciados da IBM, disponíveis em IBM Marketplace, e integram esses produtos ao seu cluster para modernizar, otimizar e executar cargas de trabalho em nuvem híbrida.
- Software livre: os Cloud Paks também podem incluir componentes de software livre para soluções de nuvem nativa e de nuvem híbrida e portátil. Normalmente, o software livre é não gerenciado e você é responsável por manter os seus componentes atualizados e seguros. No entanto, os Cloud Paks ajudam você a gerenciar consistentemente o ciclo de vida inteiro dos componentes do Cloud Pak e as cargas de trabalho que você executa com eles. Como o software de código aberto vem integrado ao Cloud Pak, você conta com os benefícios do suporte do IBM e da integração com recursos selecionados do IBM Cloud, como controle de acesso e faturamento.
Para conhecer os componentes de cada Cloud Pak, consulte a documentação em Cloud Pak.
O que mais eu preciso saber para usar o Cloud Paks?
Ao configurar seu Cloud Pak, pode ser necessário trabalhar com recursos específicos do Red Hat OpenShift, como restrições de contexto de segurança. Certifique-se de usar a CLI do oc ou a CLI do kubectl versão 1.12 para interagir com esses recursos, como oc get scc. A CLI kubectl versão 1.11 tem um bug que produz um erro ao executar comandos com relação a recursos específicos do Red Hat OpenShift, como kubectl get scc.
A IBM suporta ferramentas de terceiros e de software livre que são usadas com o cluster?
Consulte a Política de software livre e de terceiros da IBM.
Pelo que eu sou cobrado? É possível estimar e controlar custos em meu cluster?
Consulte Gerenciando os custos para seus clusters.
Posso fazer downgrade do cluster para uma versão anterior?
Não é possível fazer downgrade de seu cluster para uma versão anterior.
Posso mover meu cluster atual para uma conta diferente?
Não é possível mover o cluster para uma conta diferente daquela em que ele foi criado.
Como é possível manter o cluster em um estado suportado?
- Certifiqe-se de que o cluster sempre execute uma versão suportada do Kubernetes.
- Quando uma nova versão secundária do Kubernetes é liberada, uma versão mais antiga é descontinuada logo em seguida e, após isso, torna-se não suportada.
Para obter mais informações, consulte Atualizando o mestre e nós do trabalhador.
Quais operações serão bloqueadas se o meu cluster estiver executando um sistema operacional não suportado
As seguintes operações são bloqueadas quando um sistema operacional não é suportado:
- recarregamento do trabalhador,
- substituição do trabalhador sem atualização
- trabalhador substituir por atualização
- atualização do trabalhador
- criação do conjunto de trabalhadores (com um S.O. não suportado)
- rebalanceamento do conjunto de trabalhadores
- redimensionamento do conjunto de trabalhadores (aumento de capacidade)
- inclusão da zona do conjunto de trabalhadores
- redimensionamento do grupo de instâncias (correção)
- autoscaler remove o trabalhador (v2/autoscalerRemoveWorker)
Qual é o fuso horário padrão dos meus nós de trabalho da VPC?
A partir da versão do patch 1.32.11_1576, lançada em 27 de janeiro de 2026, todos os patches futuros para clusters VPC definem a hora local do
nó de trabalho como UTC.