O desenvolvimento pode ser comparado a uma imagem em que o artista é um desenvolvedor líder. Criando uma aplicação de microsserviço elegante - com as criações dos melhores arquitetos - modernistas. Mas para colocar o processo em andamento e deixar a oportunidade de escolher - art. No primeiro artigo da série, queremos falar sobre como o serviço IBM Kubernetes e o serviço em nuvem IBM Managed OpenShift foram criados e executados e como você pode implementar e testar seu cluster Kubernetes gratuitamente na nuvem IBM.
A nuvem da IBM vem ganhando funcionalidade nos últimos dez anos. Tudo começou com a criação de infraestruturas compartilhadas para atender grandes empresas, depois com máquinas virtuais e físicas baseadas em data centers da SoftLayer, depois houve a construção de cinco anos do PaaS (com base nos tempos de execução do Cloud Foundry) e a evolução de um grande número de serviços. A equipe de desenvolvimento de Moscou também participou da criação de parte dos serviços. Hoje, porém, não se trata de serviços, mas do que são os kubernetes gerenciados e o openshift gerenciado e como ele funciona na nuvem IBM. Muitos detalhes não podem ser informados, pois o projeto é interno, mas é possível abrir uma certa cortina.
O que é o kubernetes e como o kubernetes / openshift gerenciado é diferente de uma instalação local
O Kubernetes foi inicialmente posicionado como uma plataforma de código aberto para gerenciar aplicativos e serviços em contêiner. As principais tarefas do kubernetes são (deixarei sem tradução, para não quebrar a terminologia):
- Descoberta de serviços e balanceamento de carga
- Orquestração de armazenamento
- Lançamentos e reversões automatizados
- Embalagem automática de caixas
- Auto-cura
- Gerenciamento de segredo e configuração
Em geral, o kubernetes faz um excelente trabalho em todas essas tarefas. Por outro lado, o kubernetes começou a ser posicionado como um banco de dados para armazenar configurações de aplicativos ou uma ferramenta de API para gerenciar seus componentes (especialmente relevante no contexto do desenvolvimento de operadores).
Uma das vantagens do kubernetes é que você pode executar aplicativos em contêiner nos recursos de computação e na nuvem. No caso de recursos da nuvem - muitos provedores de nuvem fornecem a capacidade de usar recursos de computação para executar aplicativos e administrar totalmente os clusters:
- implantação de cluster
- definir disponibilidade e distribuição de rede
- instalação de atualizações e fix packs
- Configurando um cluster para aumentar a tolerância a falhas e a segurança (mais no artigo)
- ...
Se você trabalha com kubernetes gerenciados em qualquer nuvem, é claro que está limitado a várias ações. Por exemplo, várias versões do kubernetes geralmente são suportadas e é improvável que você seja capaz de usar versões do kubernetes que não são suportadas por um longo tempo. A principal vantagem é, sem dúvida, que não é sua equipe que administra os clusters, o que reduz o tempo necessário para desenvolver aplicativos. Obviamente, os kubernetes gerenciados e o openshift gerenciado não podem ser usados em todas as organizações e em qualquer tipo de aplicativo, mas há uma grande variedade de tarefas ótimas para computação nas nuvens.
Arquitetura em nuvem
Dentro da empresa, o projeto IBM Managed Kubernetes e o IBM Managed OpenShift são chamados de projeto Armada. O projeto começou com um data center, mas agora está disponível em 60 data centers em nuvem em 6 regiões diferentes. Para descrever como a nuvem é escalada, usarei dois termos: hubs e raios. Todo o projeto Armada é baseado em kubernetes, o que significa que seus clusters são controlados por um painel de controle executado em kubernetes. Assim que o painel de controle não possui recursos suficientes para gerenciar o conjunto necessário de clusters, ele implementa raios adicionais. Esses raios continuarão sendo responsáveis pelo gerenciamento de clusters em uma região específica.
O painel de controle consiste em mais de 1.500 implantações e está localizado em 60 clusters de kubernetes. Tudo isso é necessário para gerenciar mais de 15.000 clusters de nossos clientes (sem incluir clusters sem teste implantados no mesmo trabalhador).
Para criar o IKS e o OpenShift gerenciado, a equipe usou o modelo OpenSource internamente. A maioria dos funcionários da IBM tem acesso à maioria dos repositórios do Armada e pode criar seus próprios PRs para integrar seus serviços. Como parte do trabalho de serviço, também foi desenvolvido um grande número de ferramentas de CI / CD, integradas ao projeto Razee. No verão de 2019, a IBM enviou todas as conquistas do projeto Razee para o OpenSource.
Em geral, a arquitetura para IKS e Managed OpenShift é a seguinte:
Quando você trabalha com o IBM Cloud CLI e solicita a criação de um cluster, na verdade, seus pedidos vão para a API Armada, em seguida, o painel de controle determina a disponibilidade de spokes e inicia a criação do número necessário de trabalhadores nas regiões especificadas. Toda a infraestrutura para trabalhadores é fornecida usando o IBM Cloud Infrastructure (também conhecido como Soflayer); de fato, as mesmas instâncias virtuais e hosts bare metal são usados, disponíveis na seção "Computação" do catálogo de serviços em nuvem. Depois de um tempo, você receberá um token de autorização e poderá começar a implantar seus aplicativos.
Como o OpenShift e o Kubernetes diferem em seus recursos e roteiro de desenvolvimento, a pilha de tecnologia subjacente é correspondentemente diferente:
Como é garantida a segurança?
Podemos falar sobre o projeto Armada por muito tempo, tanto do ponto de vista técnico quanto do marketing. Mas, antes de tudo, ao escolher um provedor de nuvem que fornece kubernetes gerenciados, todos fazem a mesma pergunta - como o provedor garante e garante a segurança e a tolerância a falhas dos meus aplicativos? É impossível avaliar o desempenho, a conveniência e o nível de suporte do serviço sem receber uma resposta para essa pergunta. Como gerente de desenvolvimento, durante o desenvolvimento de qualquer projeto importante, eu traço um mapa das ameaças. É necessário introduzir todas as opções de hackers possíveis e proteger sua infraestrutura, aplicativos e dados. Para falar sobre a segurança do cluster kubernetes, você precisa descrever os seguintes pontos:
- segurança da própria infraestrutura e dos data centers
- acesso à API do Kubernetes e etcd
- nós de mestre e trabalhador de segurança
- segurança de rede
- segurança de armazenamento persistente
- monitoramento e registro
- segurança e imagens de contêineres
Agora, as primeiras coisas primeiro:
Segurança da infraestrutura e dos centros de dados
Não importa como gostaríamos de nos desligar completamente do hardware e da manutenção do enchimento de hardware dos sistemas de TI, na verdade, precisamos ter certeza de que o provedor de serviços cobrirá completamente nossa retaguarda e confirmar isso documentado com a ajuda de certificações industriais e do setor e, se necessário, com a ajuda de relatórios sobre realização de auditorias. Esse aspecto foi levado em consideração pela equipe IBM com toda a seriedade possível e todas as informações necessárias foram coletadas e apresentadas em um único local ( https://www.ibm.com/cloud/compliance )
Acesse a API do Kubernetes e etcd
Para acessar a API do Kubernetes e os dados no etcd, você precisa passar por três níveis de autorização. Cada token de autorização emitido está associado a tokens de autenticação, dados de autorização de cluster (RBAC) e ao controlador de Admissão (consulte o diagrama abaixo).
Como os assistentes são configurados centralmente usando raios, isso significa que você não pode alterar a configuração do assistente, os assistentes nem mesmo estão localizados na sua conta na nuvem e não são visíveis na lista de seus dispositivos (ao contrário dos trabalhadores). Todas as alterações na configuração podem ser feitas apenas dentro de certos recursos. Por um lado, isso é uma limitação, mas, devido a essa limitação, os invasores também não terão acesso aos seus assistentes; além disso, não há fator de erro humano, não há risco de usar versões incompatíveis dos componentes do kubernetes e todo o processo de administração do cluster é facilitado. Em geral, podemos dizer que a IBM é responsável por garantir a tolerância a falhas e a configuração correta do kubernetes master. Se o seu projeto possui requisitos rígidos para o uso de determinadas versões de componentes, em seu lugar, eu não examinaria os kubernetes gerenciados e usaria minha própria instalação.
Nós de mestre e trabalhador de segurança
Para garantir a segurança dos trabalhadores e do mestre dos nós, usamos túneis VPN criptografados entre os nós de computação, e o usuário tem a oportunidade de solicitar um trabalhador com discos rígidos criptografados. Também usamos o Application Armor para restringir o acesso do aplicativo aos recursos no nível do sistema operacional. O Application Armor é uma extensão do kernel do Linux para configurar o acesso a recursos para cada aplicativo.
Ao criar um cluster, depois de escolher a configuração que mais lhe convém, serão criados servidores virtuais ou baremetais, em que componentes para o trabalho de seus trabalhadores serão instalados. O usuário tem acesso ao sistema operacional do trabalhador, mas somente quando conectado via VPN de gerenciamento, o que pode ser útil para solucionar problemas e para atualizar o próprio sistema operacional do trabalhador. Não há acesso IP público por ssh. Para obter o ssh dentro do contêiner, é necessário usar o kubectl exec, essa conexão será feita através do túnel OpenVPN.
Segurança de rede
Nos kubernetes gerenciados e no openshift, um plug-in de rede Calico é usado como uma solução de virtualização de rede. A segurança da rede é alcançada por meio de políticas de rede Kubernetes e Calico pré-configuradas. Seus funcionários podem estar na mesma VLAN de todas as outras infraestruturas no mesmo datacenter, como máquinas virtuais comuns e servidores baremetal, além de aplicativos de rede e sistemas de armazenamento e, graças aos sistemas de chita localizados fora do cluster, poderá se comunicar via rede privada com suas implantações.
Quando um cluster com uma VLAN pública é criado, o painel de controle cria um recurso HostEndpoint com o ibm.role: worker_public para cada trabalhador e suas interfaces de rede externas. Para proteger interfaces de rede externas, o painel de controle aplicará todas as políticas padrão do Calico a todos os terminais com o ibm.role: worker_public .
As políticas padrão do Calico permitem todo o tráfego de saída e o tráfego de entrada da Internet para determinados componentes (serviço Kubernetes NodePort, LoadBalancer e Ingress). Todo o outro tráfego está bloqueado. As políticas padrão não se aplicam ao tráfego no cluster (interação entre os pods)
Segurança de armazenamento persistente
Para segurança no nível de persistência, criptografia e autorização de chave são usadas. Atualmente disponível para IKS:
- NFS clássico
- Armazenamento em bloco clássico (iSCSI)
- Armazenamento em bloco VP
- Armazenamento de objetos na nuvem IBM
- SDS baseado em Porworx (usa unidades locais de seus próprios trabalhadores)
Monitoramento e registro
Você pode usar o IBM Cloud Monitoring ou uma solução da Sysdig para monitorar o IKS. Naturalmente, Prometeu não ficou sem. O OpenShift gerenciado usa ferramentas de monitoramento internas.
Com os próprios logs, as coisas são mais complicadas. É necessário coletar logs de níveis completamente diferentes, usamos um grande número de soluções próprias e de código aberto. Coletamos e armazenamos os seguintes logs:
- Logs do próprio contêiner (STDOUT, STDERR)
- Logs de aplicativos (se o caminho para eles estiver especificado)
- Logs do nó de trabalho
- Logs da API do Kubernetes
- Logs de entrada
- Logs de todos os componentes do sistema Kubernetes (namespace do sistema kube)
Para controlar os logs, está disponível um serviço separado: IBM Cloud Log Analysis com LogDNA, que permite exibir todos os logs em um console comum e analisar retrospectivamente ou em tempo real, dependendo da tarifa. Você pode criar uma instância separadamente em cada uma das 6 regiões e usá-la para coletar os logs do cluster Kubernetes e outras infraestruturas da sua conta. Para conectar este serviço ao seu cluster, você precisa colocar um pod com o agente LogDNA seguindo instruções simples, e todos os logs serão enviados ao repositório LogDNA; depois, dependendo do plano escolhido, eles estarão disponíveis para análises adicionais por um determinado período.
Para analisar as atividades em seus serviços em nuvem, incluindo logins e muito mais, o Activity Tracker com LogDNA está disponível - ele permite que você rastreie várias ações em seus serviços.
Como uma ferramenta de monitoramento adicional, você pode configurar o IBM Cloud Monitoring com Sysdig em seu cluster - ele está disponível em todas as 6 regiões, o que permitirá monitorar muitas métricas em seu cluster em tempo real e usar as integrações internas com muitos ambientes comuns em execução em contêineres. Além disso, você pode configurar a reação a eventos com a possibilidade de notificações via folga, email, PagerDuty, WebHook, etc.
Segurança de contêiner e imagem de contêiner
A empresa tem sua própria opinião sobre o que está incluído no DevOps. Se alguém estiver interessado, você pode ler mais sobre isso no método IBM Garage . Compreender o que o DevSecOps também é formado em muitas empresas e aplicado na prática. Para entender os estágios em que uma imagem do Docker passa a se tornar um contêiner do Docker, vejamos a figura a seguir.
Na nuvem IBM, é possível usar o registro do Docker como um serviço. Ao enviar uma imagem para esta janela de encaixe, o registro é assinado. Na parte do nó do trabalhador, o addon é instalado, responsável por verificar a integridade e a conformidade com as políticas de segurança - Vulnerability Advisor. Usando essas políticas, você pode, por exemplo, limitar o círculo do registro, de onde é possível baixar imagens do Docker.
apiVersion: securityenforcement.admission.cloud.ibm.com/v1beta1 kind: ClusterImagePolicy metadata: name: ibmcloud-default-cluster-image-policy spec: repositories: # CoreOS Container Registry - name: "quay.io/*" policy: # Amazon Elastic Container Registry - name: "*amazonaws.com/*" policy: # IBM Container Registry - name: "registry*.bluemix.net/*" policy
O Vulnerability Advisor trabalha com contêineres em execução, varrendo-os periodicamente e detectando automaticamente pacotes instalados. Imagens do Docker com vulnerabilidades em potencial são marcadas como perigosas para uso e fornecem informações detalhadas sobre as vulnerabilidades encontradas.
O consultor de segurança é o centro para gerenciar todas as vulnerabilidades do seu aplicativo. Ele permite trabalhar com problemas e corrigi-los. Ele funciona com os resultados do Vulnerability Advisor e com o próprio cluster, aviso oportuno da necessidade de atualizar um componente específico.
Exemplo de registro e implantação de um cluster gerenciado de kubernetes
Você pode implementar e testar seu cluster Kubernetes gerenciado na nuvem IBM de forma totalmente gratuita:
- Registre-se na nuvem IBM: https://ibm.biz/rucloud (você precisa confirmar seu endereço de e-mail, não é necessário adicionar dados do cartão de crédito neste estágio)
- Para usar o serviço IKS, você pode transferir sua conta para uma paga (clicando em Atualizar e inserindo os detalhes do seu cartão bancário - você receberá US $ 200 na conta). Ou, especialmente, para os leitores do Habr, você pode obter um cupom para mudar sua conta para o modo de teste - isso permitirá que você implante um cluster mínimo gratuitamente por 30 dias. Após esse período, o cluster pode ser recriado novamente e continuar testando. Você pode solicitar um cupom no link - https://ibm.biz/cloudcoupon . A confirmação do cupom é feita durante o dia útil.
- É possível criar um cluster gratuito (um trabalhador, 2 vCPUs e 4 GB de RAM) a partir do catálogo de serviços - https://cloud.ibm.com/kubernetes/catalog/cluster/create
- Levará de 5 a 7 minutos para criar um cluster, após o qual o cluster IKS estará disponível para você.
Conclusão
Espero que, depois de ler este artigo, o leitor tenha menos perguntas sobre como o kubernetes gerenciado e o turno aberto gerenciado funcionam. Este artigo também pode ser usado como uma instrução para ação sobre como implementar seus próprios kubernetes. Todas as práticas usadas pela IBM são aplicáveis a nuvens privadas e, com algum esforço, são implementadas em qualquer data center.
Recursos
IKS folga
https://ibm-container-service.slack.com/
https://www.ibm.com/cloud/blog/announcements/ibm-cloud-activity-tracker-with-logdna-for-ibm-cloud-object-storage
https://www.ibm.com/cloud/blog/announcements/introducing-the-portworx-software-defined-storage-solution
https://cloud.ibm.com/docs/services/Monitoring-with-Sysdig?topic=Sysdig-getting-started