Quais tipos de aplicativo podem ser executados no IBM Cloud Kubernetes Service?

Aplicativos stateless

Aplicativos stateless são preferenciais para ambientes nativos de nuvem, como o Kubernetes. Eles são simples de migrar e escalar porque declaram dependências, armazenam configurações separadamente do código e tratam serviços auxiliares, como bancos de dados, como recursos conectados, em vez de acoplados ao app. Os pods de app não requerem armazenamento de dados persistente ou um endereço IP de rede estável, e como tais, os pods podem ser finalizados, reprogramados e escalados em resposta às demandas de carga de trabalho. O app usa um banco de dados como um serviço para dados persistentes e serviços NodePort, de balanceador de carga ou do Ingress para expor a carga de trabalho em um endereço IP estável.

Apps stateful

Os apps stateful são mais complicados de configurar, gerenciar e dimensionar do que os stateless porque os pods requerem dados persistentes e uma identidade de rede estável. Aplicativos stateful são, frequentemente, bancos de dados ou outras cargas de trabalho distribuídas e intensivas em dados, nas quais o processamento é mais eficiente mais próximo dos dados em si. Se desejar implementar um app stateful, será necessário configurar o armazenamento persistente e montar um volume persistente para o pod controlado por um objeto StatefulSet. É possível optar por incluir o armazenamento de arquivos, de bloco ou de objeto como o armazenamento persistente para seu conjunto stateful. Você também pode instalar o Portworx em seus nós de trabalho bare metal e usar o Portworx como uma solução de armazenamento definido por software altamente disponível para gerenciar o armazenamento persistente de seus aplicativos com estado. Para obter mais informações sobre como funcionam os conjuntos stateful, consulte a Documentação do Kubernetes.

Quais são algumas diretrizes para desenvolver apps nativos da nuvem stateless?

Confira o Twelve-Factor App, uma metodologia neutra em linguagem para considerar de que modo será desenvolvido o app em 12 fatores, resumidos conforme a seguir.

1. Base de código: use um único código base em um sistema de controle de versão para suas implementações. Ao extrair uma imagem para sua implementação de contêiner, especifique uma tag de imagem testada em vez de usar latest.
2. Dependências: declare e isole dependências externas explicitamente.
3. Configuração: armazene configurações específicas da implementação em variáveis de ambiente, não no código.
4. Serviços auxiliares: trate os serviços auxiliares, como armazenamentos de dados ou filas de mensagens, como recursos conectados ou substituíveis.
5. Estágios do aplicativo: construa em estágios distintos, como build, release e run, com separação restrita entre eles.
6. Processos: execute como um ou mais processos stateless que não compartilham nada e que usam o armazenamento persistente para salvar dados.
7. Ligação de porta: ligações de porta são autocontidas e fornecem um terminal de serviço em host e porta bem definidos.
8. Simultaneidade: gerencie e escale seu app por meio de instâncias de processo, como réplicas e dimensionamento horizontal. Configure solicitações de recurso e limites para suas implementações. Note que as políticas de rede do Calico não podem limitar a largura de banda. Em vez disso, considere o Istio.
9. Descartabilidade: projete seu app para ser descartável, com inicialização mínima, encerramento normal e tolerância para finalizações de processo abruptas. Lembre-se de que contêineres, pods e até mesmo nós do trabalhador devem ser descartáveis, portanto, planeje o seu app de forma apropriada.
10. Paridade entre desenvolvimento e produção: Configure um pipeline de integração contínua e entrega contínua para seu aplicativo, com uma diferença mínima entre o aplicativo em desenvolvimento e o aplicativo em produção.
11. Logs: trate os logs como fluxos de eventos, pois o ambiente externo ou de hospedagem processa e roteia arquivos de log. Importante: no IBM Cloud Kubernetes Service, os logs não são ativados por padrão. Para ativá-los, consulte Configurando o encaminhamento de log.
12. Processos de administração: mantenha os scripts de administração únicos com o app e execute-os como um Objeto de tarefa do Kubernetes para assegurar que os scripts de administração sejam executados com o mesmo ambiente do próprio app. Para orquestração de pacotes maiores que você deseja executar nos clusters do Kubernetes, considere usar um gerenciador de pacote, tal como o Helm.

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.

Já tenho um app. Como migrá-lo para o IBM Cloud Kubernetes Service?

A seguir, é possível executar algumas etapas gerais para conteinerizar seu app.

1. Use o Twelve-Factor App como um guia para isolar dependências, separando processos em serviços distintos e reduzindo o máximo possível do statefulness do app.
2. Localize uma imagem base apropriada a ser usada. É possível usar imagens disponíveis publicamente do Docker Hub, imagens públicas da IBM ou construir e gerenciar as suas próprias no IBM Cloud Container Registry privado.
3. Inclua em sua imagem do Docker somente o que for necessário para executar o app.
4. Em vez de depender do armazenamento local, planeje-se para usar o armazenamento persistente ou soluções de banco de dados como um serviço de nuvem para fazer backup dos dados do seu app.
5. Com o tempo, refatore os processos de seu app em microsserviços.

Pensei que precisava colocar meu app em um contêiner. No entanto, o que são essas informações sobre pods?

Um pod é a menor unidade implementável que o Kubernetes pode gerenciar. Você coloca seu contêiner (ou um grupo de contêineres) em um pod e usa o arquivo de configuração de pod para informá-lo sobre como executar o contêiner e compartilhar recursos com outros pods. Todos os contêineres que você coloca em um pod são executados em um contexto compartilhado, o que significa que eles compartilham a máquina virtual ou física.

O que colocar em um contêiner

Ao pensar nos componentes do aplicativo, verifique se há requisitos de recursos significativamente diferentes para itens como CPU e memória. É possível que alguns componentes funcionem de maneira bastante intensa, sendo aceitável que fiquem inativos brevemente para desviar recursos para outras áreas? Há algum outro componente voltado ao cliente, de maneira que seja fundamental que ele permaneça ativo? Divida-os em contêineres separados. É sempre possível implementá-los no mesmo pod para que sejam executados em sincronia.

O que colocar em um pod

Os contêineres de seu aplicativo não precisam estar sempre no mesmo pod. Na verdade, se você tiver um componente stateful difícil de dimensionar, como um serviço de banco de dados, coloque-o em um pod diferente que possa ser planejado em um nó do trabalhador com mais recursos para manipular a carga de trabalho. Se seus contêineres funcionarem corretamente se eles forem executados em nós do trabalhador diferentes, use diversos pods. Se precisarem estar na mesma máquina e ter seu dimensionamento realizado em conjunto, agrupe-os no mesmo pod.

Então, se posso usar um pod, por que preciso de todos esses tipos diferentes de objetos?

Criar um arquivo YAML de pod é fácil. É possível escrever um com apenas algumas linhas, conforme a seguir.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Mas ainda há mais possibilidades. Se o nó no qual seu pod é executado ficar inativo, seu pod também ficará e não será reprogramado. Em vez disso, use uma implementação para suportar o replanejamento de pod, conjuntos de réplicas e atualizações contínuas. Uma implementação básica é praticamente tão fácil de fazer quanto um pod. Em vez de definir o contêiner no spec por si só, no entanto, você especifica replicas e um template no spec da implementação. O modelo possui seu próprio spec para os contêineres dentro dele, como a seguir.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

É possível continuar incluindo recursos, como antiafinidade de pod ou limites de recurso, todos no mesmo arquivo YAML.

Para obter uma explicação mais detalhada dos diferentes recursos que você pode adicionar à sua implantação, consulte Como criar o arquivo YAML de implantação do aplicativo.

Quais tipos de objetos do Kubernetes podem ser feitos para o app?

Ao preparar seu arquivo YAML do app, você tem muitas opções para aumentar a disponibilidade, o desempenho e a segurança do app. Por exemplo, em vez de um único pod, é possível usar um objeto de controlador do Kubernetes para gerenciar sua carga de trabalho, como um conjunto de réplicas, uma tarefa ou um conjunto de daemons. Para obter mais informações sobre pods e controladores, visualize a Documentação de Kubernetes. Uma implementação que gerencia um conjunto de réplicas de pods é um caso de uso comum para um app.

Por exemplo, um objeto kind: Deployment é uma boa opção para implementar um pod de app porque, com ele, é possível especificar um conjunto de réplicas para obter mais disponibilidade para seus pods.

A tabela a seguir descreve por que é possível criar diferentes tipos de objetos de carga de trabalho do Kubernetes.

E se eu quiser minha configuração de app para usar variáveis? Como faço para adicionar essas variáveis ao YAML?

Para adicionar informações variáveis às suas implantações em vez de codificar os dados no arquivo YAML, você pode usar um Kubernetes ConfigMap ou Secret objeto.

Para consumir um configmap ou segredo, é necessário montá-lo no pod. O configmap ou segredo é combinado com o pod exatamente antes de o pod ser executado. É possível reutilizar uma especificação de implementação e imagem em muitos apps, mas, em seguida, descarregar para a área de troca os configmaps e segredos customizados. Os segredos em particular podem ocupar muito armazenamento no nó local, portanto, planeje adequadamente.

Ambos os recursos definem os pares chave-valor, mas são usados para diferentes situações.

Configmap

Forneça informações de configuração não confidenciais para cargas de trabalho que são especificadas em uma implementação. É possível usar configmaps de três maneiras principais.

• Sistema de arquivos: É possível montar um arquivo inteiro ou conjunto de variáveis em um pod. Um arquivo é criado para cada entrada com base nos conteúdos de nome da chave do arquivo que são configurados para o valor.
• Variável de ambiente: Configure dinamicamente a variável de ambiente para uma especificação de contêiner.
• Opção de linha de comando: Defina a opção de linha de comando que é usada em uma especificação de contêiner.

Segredo

Forneça informações confidenciais para suas cargas de trabalho, como a seguir. Outros usuários do cluster podem ter acesso ao segredo, portanto, certifique-se de que você saiba que as informações secretas podem ser compartilhadas com esses usuários.

• Informações pessoalmente identificáveis (PII): Armazene informações confidenciais, como endereços de e-mail ou outros tipos de informações necessárias para a conformidade da empresa ou regulamentação do governo em segredos.
• Credenciais: Coloque credenciais como senhas, chaves e tokens em um segredo para reduzir o risco de exposição acidental. Por exemplo, quando você liga um serviço a seu cluster, as credenciais são armazenadas em um segredo.

Deseja tornar seus segredos ainda mais seguros? Peça ao seu administrador de cluster para ativar um provedor de serviço de gerenciamento de chave em seu cluster para criptografar segredos novos e existentes.

Como posso ter certeza de que meu aplicativo tem os recursos corretos?

Ao especificar o arquivo YAML do aplicativo, você pode adicionar funcionalidades do Kubernetes à configuração do aplicativo que o ajudam a obter os recursos corretos. Em particular, configure limites e solicitações de recursos para cada contêiner definido no arquivo YAML.

Além disso, seu administrador de cluster pode configurar controles de recurso que podem afetar a implementação do app, conforme a seguir.

• Cotas de recursos
• Prioridade de Pod

Como incluir recursos em minha configuração de app?

Veja Especificando seus requisitos de app em seu arquivo YAML para obter descrições do que você pode incluir em uma implementação. O exemplo inclui as seguintes opções.

• Conjuntos de réplicas
• Rótulos
• Afinidade
• Políticas de imagem
• Portas
• Solicitações e limites de recursos
• Análises de vivacidade e prontidão
• Serviços para expor o serviço do aplicativo em uma porta.
• Configmaps para configurar variáveis de ambiente de container.
• Segredos para configurar variáveis de ambiente de container.
• Volumes persistentes que são montados no contêiner para armazenamento.

Como é possível incluir serviços IBM em meu app, como Watson?

Consulte Incluindo serviços em apps .

Como aumentar a disponibilidade do meu app?

Considere as opções a seguir para aumentar a disponibilidade de seu app.

Usar implementações e conjuntos de réplicas para implementar seu app e suas dependências

Uma implementação é um recurso de Kubernetes que você pode usar para declarar todos os componentes do seu app e suas dependências. Com as implementações, não é preciso anotar todas as etapas e é possível se concentrar no app. Ao implementar mais de um pod, um conjunto de réplicas é criado automaticamente para suas implementações que monitora os pods e garante que o número especificado de pods esteja em funcionamento. Quando um pod fica inativo, o conjunto de réplicas substitui o pod não responsivo por um novo. É possível usar uma implementação para definir estratégias de atualização para seu app, incluindo o número de pods que você deseja incluir durante uma atualização contínua e o número de pods que podem estar indisponíveis por vez. Quando você executa uma atualização contínua, a implementação verifica se a revisão está funcionando e para o lançamento quando falhas são detectadas. Com as implementações, você pode implementar simultaneamente várias revisões com diferentes opções. Por exemplo, é possível testar uma implementação primeiro antes de decidir enviá-la por push para a produção. Usando Implementações, é possível rastrear qualquer revisão implementada. Será possível usar esse histórico para recuperar uma versão anterior se você descobrir que as suas atualizações não estão funcionando conforme o esperado.

Incluir réplicas suficientes para a carga de trabalho de seu app, mais duas

Para tornar seu app ainda mais altamente disponível e mais resiliente à falha, considere a inclusão de réplicas adicionais, além do mínimo, para manipular a carga de trabalho esperada. As réplicas adicionais podem manipular a carga de trabalho no caso de um pod travar e o conjunto de réplicas ainda não ter recuperado o pod travado. Para proteção contra duas falhas simultâneas, inclua duas réplicas adicionais. Essa configuração é um padrão N + 2, em que N é o número de réplicas para manipular a carga de trabalho recebida e + 2 são duas réplicas adicionais. Desde que seu cluster tenha espaço suficiente, será possível ter tantos pods quantos você quiser.

Difundir pods em diversos nós (antiafinidade)

Quando você cria a sua implementação, cada pod pode ser implementado no mesmo nó do trabalhador. Isso é conhecido como afinidade ou colocation. Para proteger seu app contra falha do nó do trabalhador, será possível configurar sua implementação para difundir os pods em diversos nós do trabalhador usando a opção podAntiAffinity com seus clusters padrão. É possível definir dois tipos de antiafinidade do pod: preferencial ou necessário. Para obter mais informações, consulte a documentação do Kubernetes em Designando pods a nós.

Para obter um exemplo de afinidade em uma implementação de app, veja Fazendo seu arquivo YAML de implementação de app.

Distribuir pods em diversas zonas ou regiões

Para proteger seu app de uma falha de zona, é possível criar diversos clusters em zonas separadas ou incluir zonas em um conjunto de trabalhadores em um cluster de diversas zonas. Os clusters multizona estão disponíveis somente em certas multizonas clássicas ou VPC, como Dallas. Se você cria múltiplos clusters em zonas separadas, deve-se configurar um balanceador de carga global. Ao usar um conjunto de réplicas e especificar a antiafinidade do pod, o Kubernetes difunde seus pods de app entre os nós. Se os seus nós estiverem em diversas zonas, os pods serão distribuídos pelas zonas, aumentando a disponibilidade do seu app. Se você desejar limitar seus apps para serem executados somente em uma zona, será possível configurar a afinidade de pod ou criar e rotular um conjunto de trabalhadores em uma zona.

Em uma implantação de cluster de várias zonas, meus pods de aplicativos são distribuídos uniformemente entre os nós?

Os pods são distribuídos uniformemente entre as zonas, mas nem sempre entre os nós. Por exemplo, se você tiver um cluster com um nó em cada uma das três zonas e implementar um conjunto de réplicas de seis pods, cada nó obterá dois pods. No entanto, se você tiver um cluster com dois nós em cada uma das três zonas e implementar um conjunto de réplicas de seis pods, cada zona planejará dois pods e poderá planejar um pod por nó ou não. Para ter mais controle sobre o agendamento, você pode definir a afinidade do pod.

Se uma zona ficar inativa, como os pods serão reagendados para os nós restantes nas outras zonas?

Isso depende da política de planejamento que você usou na implementação. Se você incluiu a afinidade de pod específica do nó, seus pods não serão reprogramados. Se você não tiver feito isso, os pods serão criados em nós do trabalhador disponíveis em outras zonas, mas eles podem não ser balanceados. Por exemplo, os dois pods podem ser distribuídos entre os dois nós disponíveis ou ambos podem ser planejados em um nó com capacidade disponível. Da mesma forma, quando a zona indisponível retornar, os pods não serão excluídos e rebalanceados automaticamente entre os nós. Se você quiser que os pods sejam rebalanceados entre as zonas depois que a zona for restabelecida, configure o desescalonador Kubernetes. Em clusters de várias zonas, tente manter a capacidade do nó de trabalho em 50% por zona para que haja capacidade suficiente para proteger o cluster contra uma falha zonal.

E se eu quiser distribuir meu aplicativo em várias regiões?

Para proteger seu aplicativo de uma falha de região, crie um segundo cluster em outra região, configure um balanceador de carga global para conectar seus clusters e use um YAML de implantação para implantar um conjunto de réplicas duplicado com antiafinidade de pod para seu aplicativo.

E se meus aplicativos precisarem de armazenamento persistente?

Use um serviço de nuvem como o IBM Cloudant ou o IBM Cloud Object Storage.

Como escalar meu app?

Se você desejar incluir e remover dinamicamente apps em resposta ao uso de carga de trabalho, consulte Escalando apps para obter etapas para ativar o ajuste automático de escala do pod horizontal.

Como é possível organizar as implementações para torná-las mais fáceis de atualizar e gerenciar?

Agora que você compreendeu o que pode incluir em sua implementação, pode ocorrer a dúvida sobre como gerenciar todos esses arquivos YAML diferentes. Isso sem mencionar os objetos que eles criam em seu ambiente do Kubernetes.

As dicas a seguir vão ajudá-lo a organizar seus arquivos YAML de implementação.

• Use um sistema de controle de versão, como o Git.
• Agrupe objetos do Kubernetes estritamente relacionados em um único arquivo YAML. Por exemplo, se estiver criando uma deployment, também será possível incluir o arquivo service no YAML. Objetos separados com ---, como no exemplo a seguir.

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  ...
  ---
  apiVersion: v1
  kind: Service
  metadata:
  ...
  

• É possível usar o comando kubectl apply -f para aplicar a um diretório inteiro, não apenas a um único arquivo.
• Experimente o projeto kustomize que pode ser usado para ajudar a gravar, customizar e reutilizar as configurações de YAML do recurso do Kubernetes.

Dentro do arquivo YAML, é possível usar rótulos ou anotações, como metadados, para gerenciar suas implementações.

Rótulos

Rótulos são pares key:value que podem ser anexados a objetos Kubernetes, como pods e implementações. Eles podem ser o que você desejar e são úteis para selecionar objetos com base nas informações do rótulo. Rótulos fornecem a base para agrupar objetos. Consulte os exemplos abaixo com ideias de rótulos.

• app: nginx
• version: v1
• env: dev

Anotações

Anotações são semelhantes a rótulos no sentido de serem também pares key:value. Elas são melhores para informações não identificadas que podem ser utilizadas por ferramentas ou bibliotecas, como a retenção de informações adicionais sobre o local de origem de um objeto, como usá-lo, ponteiros para repositórios de rastreamento relacionados ou uma política sobre o objeto. Objetos não são selecionados com base em anotações.

Quais estratégias de atualização de app podem ser usadas?

Para atualizar o seu app, é possível escolher entre várias estratégias como as seguintes. É possível começar com uma implementação contínua ou uma alternância instantânea antes de continuar para uma implementação canary mais complicada.

Implementação contínua

É possível usar a funcionalidade nativa do Kubernetes para criar uma implementação da v2 e substituir gradualmente sua implementação anterior da v1. Essa abordagem exige que os aplicativos sejam compatíveis com a versão anterior, para que os usuários que recebem a versão do aplicativo v2 não sofram nenhuma alteração significativa. Para obter mais informações, consulte Gerenciando implementações contínuas para atualizar seus apps.

Alternância instantânea

Também conhecida como uma implementação azul-verde, uma alternância instantânea requer o dobro dos recursos de cálculo para ter duas versões de um mesmo app em execução ao mesmo tempo. Com essa abordagem, é possível alternar seus usuários para a versão mais recente em tempo quase real. Certifique-se de usar seletores de rótulo de serviço (como version: green e version: blue) para garantir que as solicitações sejam enviadas para a versão correta do aplicativo. É possível criar a nova implementação version: green, aguardar até que ela esteja pronta e, em seguida, excluir a implementação version: blue. Ou é possível executar uma atualização contínua, mas configurar o parâmetro maxUnavailable para 0% e o parâmetro maxSurge para 100%.

Implementação canary ou A/B

Uma implementação canary, que é uma estratégia de atualização mais complexa, consiste na escolha de uma porcentagem de usuários, como 5%, e seu envio para a nova versão do app. Você coleta métricas em suas ferramentas de criação de log e monitoramento sobre como a nova versão do app está sendo executada, realiza testes A/B e, em seguida, apresenta a atualização para mais usuários. Como com todas as implementações, rotular o app (como version: stable e version: canary) é crítico. Para gerenciar implementações canárias, é possível instalar a malha de serviço do complemento do Istio gerenciado, configurar o Monitoring para o cluster e, em seguida, usar a malha de serviço do Istio para teste A/B, conforme descrito nesta postagem do blog.

Como é possível automatizar a implementação do app?

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. Com o IBM Cloud e outras ferramentas de software livre, é possível empacotar seu aplicativo para ajudar a automatizar implementações.

Configurar um pipeline de integração e entrega contínuas (CI/CD)

Com os arquivos de configuração de seu app organizados em um sistema de gerenciamento de controle de origem, como o Git, é possível construir seu pipeline para testar e implementar códigos em diferentes ambientes, como test e prod. Trabalhe com o administrador do cluster para configurar integração e entrega contínuas.

Empacotar os arquivos de configuração de seu app

Empacote seu app com ferramentas como Kustomize ou Helm.

• Com o projeto kustomize Kustomize, é possível escrever, customizar e reaproveitar as configurações YAML de recursos do Kubernetes.
• Com o gerenciador de pacote Helm do Kubernetes, é possível especificar todos os recursos do Kubernetes que o app requer em um gráfico do Helm. Em seguida, é possível usar o Helm para criar os arquivos de configuração YAML e implementá-los em seu cluster. Também é possível integrar gráficos do Helm fornecidos pela IBM Cloud para ampliar os recursos do seu cluster, como com um plug-in de armazenamento de bloco.

Deseja criar modelos de arquivo YAML? Algumas pessoas usam o Helm exatamente para isso, ou é possível experimentar outras ferramentas da comunidade, como ytt.

Como posso ter certeza de que meus serviços estão conectados às implantações corretas e prontos para funcionar?

Para a maioria dos serviços, inclua um seletor em seu arquivo de serviço .yaml para que ele seja aplicado aos pods que executam seus apps por esse rótulo. Muitas vezes, quando seu aplicativo é iniciado pela primeira vez, você não quer que ele processe as solicitações imediatamente. Inclua uma análise de prontidão em sua implementação para que o tráfego seja enviado apenas para um pod considerado pronto. Para um exemplo de implementação com um serviço que usa rótulos e configura uma análise de prontidão, confira este YAML do NGINX.

Às vezes, você não deseja que o serviço use um rótulo. Por exemplo, é possível que você tenha um banco de dados externo ou deseje apontar o serviço para outro serviço em um namespace diferente dentro do cluster. Quando isso acontecer, será preciso incluir manualmente um objeto de terminais e vinculá-lo ao serviço.

Como é possível expor os serviços na Internet?

É possível criar três tipos de serviços para a rede externa: NodePort, LoadBalancer e Ingress.

Você tem diferentes opções que dependem de seu tipo de cluster. Para obter mais informações, consulte Planejando serviços de rede.

• Cluster padrão: é possível expor seu app usando um serviço NodePort, balanceador de carga ou Ingress.
• Cluster que se torna privado usando o Calico: é possível expor seu app usando um serviço NodePort, balanceador de carga ou Ingress. Deve-se também usar uma política de rede preDNAT do Calico para bloquear as portas de nó público.
• Cluster padrão somente de VLAN privada: é possível expor seu app usando um serviço NodePort, balanceador de carga ou Ingress. Deve-se também abrir a porta para o endereço IP privado do serviço em seu firewall.

À medida que planeja quantos objetos Service são necessários em seu cluster, tenha em mente que o Kubernetes usa iptables para manipular regras de encaminhamento de rede e porta. Se você executar muitos serviços no cluster, por exemplo, 5000, o desempenho poderá ser impactado.

É possível controlar quem tem acesso às implementações do app?

Os administradores de conta e de cluster podem controlar o acesso em muitos níveis diferentes: o cluster, o namespace do Kubernetes, o pod e o contêiner.

Com o IBM Cloud IAM, é possível designar permissões a usuários individuais, grupos ou contas de serviço no nível de instância de cluster. É possível definir o escopo de acesso do cluster ainda mais, restringindo os usuários a namespaces específicos dentro do cluster. Para obter mais informações, veja Designando acesso ao cluster.

Para controlar o acesso no nível do pod, você pode configurar as políticas de segurança do pod (PSPs).

Dentro do YAML de implementação do app, é possível configurar o contexto de segurança para um pod ou contêiner. Para obter mais informações, revise a Documentação do Kubernetes.

Após a implementação do app, como é possível monitorar seu funcionamento?

É possível configurar IBM Cloud criação de log e monitoramento para o seu cluster. Também é possível escolher integrar a um serviço de criação de log ou de monitoramento de terceiros.