Base de conhecimento  /  Gerenciador de aplicativos em nuvem  /  Automatização de implementações
Base de conhecimento  /  Gerenciador de aplicativos em nuvem  /  Automatização de implementações

Uso de Kubernetes

Atualizado por Dénes Pál em jan 2, 2019
Código do artigo: kb/1197

Neste artigo:

Visão geral

Com o provedor do Kubernetes do Cloud Application Manager, você pode criar e gerenciar qualquer recurso do Kubernetes, usando template boxes com modelos YAML declarativos.

Público

Todos os usuários do Cloud Application Manager pretendiam usar um provedor do Kubernetes.

Pré-requisitos

Guia de introdução do Kubernetes no Cloud Application Manager

Este artigo é a segunda parte de uma série e exige que um provedor do Kubernetes já esteja configurado com o Cloud Application Manager. As instruções detalhadas sobre como configurar um provedor do Kubernetes podem ser encontradas na primeira parte deste artigo.

Políticas de implementação para o Kubernetes

As políticas de implementação do Kubernetes estão vinculadas a um Namespace. A implementação no Kubernetes está limitada a um único namespace, que é definido na Política de implementação selecionada.

Quando o Cloud Application Manager sincroniza pela primeira vez o provedor do Kubernetes, ele cria uma Caixa de política de implementação de amostra apontando para o namespace padrão ou, se indisponível, para o kube-public ou então ao primeiro namespace disponível.

Caixa de política criada automaticamente de um provedor do Kubernetes

Você pode criar políticas de implementação adicionais clonando a amostra ou navegando para Caixas ->Novo -> Política de implementação e selecionando Kubernetes como o tipo.

Como criar uma nova Caixa de Política do Kubernetes

Você pode alterar o namespace associado a uma Política de Implementação editando a Política na guia Código da Caixa de Política.

Alteração do namespace de uma Caixa de Política do Kubernetes

Criar uma caixa de modelo

Vá para Caixas -> Novo -> Modelo e selecione Kubernetes como o tipo.

Como criar uma nova Template Box do Kubernetes

Preencha os parâmetros como de costume. Lembre-se de que, se você definir quaisquer Requisitos na Template Box, também precisará listá-los em uma Caixa de política de implementação como Reivindicações para poder implementar o modelo usando essa política.

Detalhes de uma nova caixa de modelos Kubernetes

Uma caixa de modelos Kubernetes pode ter vários arquivos de modelo, atualmente apenas no formato YAML, mas o Cloud Application Manager também suporta a sintaxe Jinja com YAML. Você pode alterar a ordem dos arquivos de modelo arrastando com o mouse ou pressionando e arrastando em um dispositivo com tela sensível ao toque. Pelo menos um arquivo de modelo é necessário para implementar uma template box do Kubernetes.

Template box do Kubernetes com vários modelos

No YAML, é válido definir vários documentos em um único arquivo, separados por uma linha com apenas três traços, conforme mostrado no trecho de código abaixo:

...
            memory: 100Mi
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: frontend-{{ service }}
  namespace: {{ namespace }}
...

Os modelos do Kubernetes não devem incluir uma propriedade permanente de namespace em seus metadados. Como o namespace é determinado e forçado pela Caixa de políticas de implementação usada para implementar a Instância, a implementação falhará se o modelo solicitar um namespace diferente daquele definido com a Política. O namespace definido na política de implementação pode ser referido com a variável namespace.

Se quiser implementar a mesma template box várias vezes com a mesma política de implementação (e, portanto, no mesmo namespace), para evitar conflitos de nomes, será preciso incluir o valor do ID de serviço do Cloud Application Manager no nome dos recursos implementados, e talvez nos rótulos e seletores também. Use a sintaxe YAML para colar o ID de serviço nos modelos, conforme mostrado abaixo:

apiVersion: v1
kind: Service
metadata:
  name: frontend-{{ service }}
  namespace: {{ namespace }}
...

As seguintes variáveis ​​Jinja estão sempre disponíveis em modelos:

Variável Descrição
meio ambiente Nome da instância
us$/instância ID de instância
namespace Namespace atual da política de implementação
serviço ID de serviço
tags Lista de tags
workspace Espaço de trabalho ou proprietário da instância

A caixa de diálogo novo modelo oferece as seguintes opções:

  • Criar modelo em branco especificando seu nome de arquivo (siga a convenção *.yaml)
  • Carregar um arquivo de modelo YAML do disco
  • Fazer download de um modelo YAML da URL remota
  • Importar modelos YAML de um arquivo ou diretório no GitHub

Como importar modelos do Kubernetes de um repositório do Github

Se a URL for um repositório do GitHub, os arquivos desse diretório serão importados automaticamente, desde que o nome do arquivo termine com .yaml

Existem alguns modelos de amostra para testar as implementações do Kubernetes no repositório do GitHub.

Se já houver um arquivo de modelo com esse nome, ele não será substituído, mas os nomes duplicados bloquearão a inclusão de novos modelos, portanto, um deles deve ser excluído para dar continuidade.

Como implementar template boxes do Kubernetes

Ao implementar uma template box, você precisa selecionar uma política de implementação adequada do Kubernetes, com reivindicações correspondentes aos requisitos definidos na sua template box.

Pontos de extremidade de um recurso de serviço no Kubernetes

Na implementação, o Cloud Application Manager analisará os modelos, primeiro executando instruções e substituições de variáveis ​​do Jinja e, em seguida, analisando os documentos YAML como recursos. Para cada recurso definido nos modelos, o Cloud Application Manager adiciona alguns rótulos e anotações e, em seguida, os envia um por um ao cluster do Kubernetes para criar novos recursos ou atualizar os já existentes. Se um recurso já existir, o Cloud Application Manager gerará um patch com relação à versão anterior do modelo (armazenado como uma anotação no recurso do Kubernetes), ou com relação à especificação atual do recurso lido no cluster do Kubernetes. (Em alguns casos, a abordagem posterior pode falhar: caso o recurso tenha sido criado ou modificado fora do Cloud Application Manager, por exemplo.)

Como implementar uma instância no Kubernetes

Pontos de extremidade

O Cloud Application Manager verifica os recursos implementados, procura a propriedade balanceador de carga em seus status e coleta endereços IP ou nomes de host de entrada e preenche a guia pontos de extremidade com eles.

Pontos de extremidade de um recurso de serviço no Kubernetes

Os pontos de extremidade são coletados após a implementação ou reconfiguração de uma instância.

Variáveis de saída

Não há como definir variáveis ​​de saída em modelos do Kubernetes, mas o Cloud Application Manager criará algumas variáveis ​​de saída dos pontos de extremidade encontrados na implementação, como name_Address, name_Kind, name_Port e name _Protocol.

Você pode ver as variáveis ​​de saída de qualquer instância implementada no Editor de ciclo de vida.

Editor de ciclo de vida de uma instância no Kubernetes

Lista de recursos implementados

Os recursos que foram criados com a implementação são mostrados na guia Recursos da página Detalhes da instância. A lista de recursos é limpa quando a instância é finalizada.

Recursos do Kubernetes implementados de uma instância

Os recursos são coletados após a implementação ou reconfiguração de uma instância.

Como descobrir e registrar recursos existentes

Os recursos já existentes no cluster são descobertos ao sincronizar o provedor do Kubernetes e são mostrados na guia Recursos não registrados do provedor e também na página Instâncias como Não registrados.

Guia Recursos não registrados de um provedor do Kubernetes

É possível importar um recurso não registrado, clicando no símbolo da seta na coluna da extrema direita da tabela.

Importando um recurso não registrado do Kubernetes

Ao registrar um recurso, o Cloud Application Manager cria uma Instance Box para o recurso e a preenche com um modelo que representa o esquema atual do recurso no cluster. Ele também atualiza o recurso no cluster com anotações e rótulos.

Editor de ciclo de vida mostrando o modelo de um recurso importado do Kubernetes

Depois que o recurso é importado como uma instância, ele pode ser reconfigurado ou encerrado normalmente. Se algum endereço de entrada pertencer ao recurso, ele será listado na guia Pontos de extremidade e também será exposto como variável de saída.

Instância de um recurso importado do Kubernetes

Como obter suporte geral

Os clientes podem contatar diretamente a central de suporte de operações globais da Lumen (suporte técnico) para obter ajuda com o Cloud Application Manager, bem como para qualquer outro produto compatível no qual eles estejam inscritos. Veja abaixo as três formas de obter ajuda.

Contato:

  1. Telefone: 888-638-6771

  2. E-mail: E-mail: incident@centurylink.com

  3. Criar um ticket no Cloud Application Manager: Diretamente dentro da plataforma, os usuários podem "Criar ticket" clicando no símbolo "?" no canto superior direito, próximo ao ícone do perfil de login do usuário. Isso leva o usuário diretamente ao Portal de serviços gerenciados, onde ele pode abrir, rastrear e revisar o status dos problemas que foram relatados ao suporte técnico. Além disso, essa é também a maneira de envolver um TAM.

Instruções:

  1. Informe seu nome
  2. Nome da conta do Cloud Application Manager
  3. Uma breve descrição da solicitação ou do problema para fins de registro do caso

O suporte técnico transmitirá as informações ao TAM principal e transferirá a chamada, caso necessário.

Powered by Translations.com GlobalLink OneLink SoftwarePowered By OneLink