A
plataforma Red Hat OpenShift Container Platform 4 permite transmitir a criação de
hosts para a implantação de contêineres , inclusive na infraestrutura de provedores de serviços em nuvem, em plataformas de virtualização ou em sistemas bare-metal. Para criar uma plataforma de nuvem em todo o sentido, tivemos que assumir um controle rígido de todos os elementos usados e, assim, aumentar a confiabilidade de um processo de automação complexo.
A solução óbvia foi usar o Red Hat Enterprise Linux CoreOS (uma variação do Red Hat Enterprise Linux) e o CRI-O como padrão, e aqui está o porquê ...
Como o tópico da navegação é muito bem-sucedido para encontrar analogias na explicação da operação de Kubernetes e contêineres, vamos tentar falar sobre os problemas de negócios que o CoreOS e o CRI-O resolvem, usando o exemplo da
invenção de
Brunel para a produção de blocos de rigging . Em 1803, Mark Brunel recebeu a tarefa de fabricar 100.000 blocos de cordame para as necessidades da crescente marinha britânica. Um bloco de elevação é um tipo de equipamento usado para prender cordas às velas. Até o início do século 19, esses blocos eram feitos à mão, mas Brunel era capaz de automatizar a produção e começou a produzir blocos padronizados usando máquinas. A automação desse processo significou que, como resultado, todos os blocos eram quase os mesmos, poderiam ser facilmente substituídos em caso de avaria e poderiam ser feitos em grandes quantidades.
Agora imagine que Brunel teria que fazer esse trabalho para 20 modelos de navios diferentes (versões Kubernetes) e para cinco planetas diferentes com correntes e ventos marítimos completamente diferentes (provedores de nuvem). Além disso, era necessário que todos os navios (clusters OpenShift), independentemente dos planetas navegados, se comportassem de forma idêntica do ponto de vista dos capitães (operadores que controlam a operação dos clusters). Continuando a analogia marítima, os capitães de navios não se importam absolutamente com os blocos de aparelhamento (CRI-O) usados em seus navios - a principal coisa para eles é que esses blocos são fortes e confiáveis.
O OpenShift 4, como plataforma de nuvem, enfrenta um desafio comercial muito semelhante. Novos nós devem ser criados no momento da criação do cluster, no caso de uma falha em um dos nós ou ao dimensionar o cluster. Ao criar e inicializar um novo nó, os componentes críticos do host, incluindo o CRI-O, devem ser configurados de acordo. Como em qualquer outra produção, as “matérias-primas” devem ser fornecidas no início. No caso de navios, metal e madeira atuam como matéria-prima. No entanto, se você criar um host para implantar contêineres em um cluster OpenShift 4, deverá ter arquivos de configuração e servidores de API fornecidos na entrada. Depois disso, o OpenShift fornecerá o nível de automação necessário ao longo de todo o ciclo de vida, oferecendo o suporte necessário ao produto para os usuários finais e, dessa forma, compensando os investimentos na plataforma.
O OpenShift 4 foi criado de forma a fornecer a capacidade de atualizar convenientemente o sistema durante todo o ciclo de vida da plataforma (para as versões 4.X) para todos os principais fornecedores de computação em nuvem, plataformas de virtualização e até sistemas bare metal. Para isso, os nós devem ser criados com base em elementos intercambiáveis. Quando um cluster exige uma nova versão do Kubernetes, ele também recebe a versão CRI-O correspondente no CoreOS. Como a versão do CRI-O está vinculada diretamente ao Kubernetes, tudo isso simplifica muito qualquer permutação para teste, solução de problemas ou suporte. Além disso, essa abordagem reduz os custos para usuários finais e Red Hat.
Essa é uma visão fundamentalmente nova dos clusters Kubernetes, que estabelece as bases para o planejamento de novos recursos altamente úteis e atraentes. O CRI-O (interface de tempo de execução do container Container Project - Open Container Initiative, abreviado CRI-OCI) foi a opção mais bem-sucedida para criação em massa de nós, necessária para trabalhar com o OpenShift. O CRI-O substituirá o mecanismo Docker usado anteriormente, oferecendo aos usuários do OpenShift um mecanismo
econômico, estável, simples e chato - sim, você ouviu direito - um contêiner chato projetado especificamente para trabalhar com o Kubernetes.
O mundo dos contêineres abertos
O mundo vem se movendo em direção a contêineres abertos. Seja em Kubernetes ou em níveis mais baixos, o
desenvolvimento de padrões de contêineres leva a um ecossistema de inovação em todos os níveis.
Tudo começou com a criação da Open Containers Initiative
em junho de 2015 . Nesse estágio inicial do trabalho, as especificações para a
imagem do container
(imagem) e o
tempo de execução foram formadas. Isso tornou possível garantir que as ferramentas possam usar um único padrão de
imagens de
contêiner e um único formato para trabalhar com elas.
Mais tarde, foram adicionadas especificações de
distribuição , que permitiam aos usuários trocar facilmente
imagens de contêineres .
A comunidade Kubernetes desenvolveu um único padrão de interface conectável chamado
Container Runtime Interface (CRI) . Graças a isso, os usuários do Kubernetes puderam conectar vários mecanismos para trabalhar com contêineres, além do Docker.
Os engenheiros da Red Hat e do Google viram uma demanda de mercado por um mecanismo de contêiner que pudesse aceitar solicitações da Kubelet usando o protocolo CRI e introduziu contêineres compatíveis com as especificações OCI mencionadas acima. Então
havia um OCID . Mas com licença, porque dissemos que esse material será dedicado ao CRI-O? De fato, apenas com o lançamento da
versão 1.0, o projeto foi renomeado para CRI-O.
Fig. 1Inovação com CRI-O e CoreOS
Com o lançamento da plataforma OpenShift 4, o
mecanismo de contêiner usado na plataforma padrão foi alterado e o Docker foi substituído pelo CRI-O, que oferecia um ambiente de lançamento de contêiner econômico, estável, simples e chato que se desenvolve paralelamente ao Kubernetes. Isso simplifica bastante o suporte e a configuração do cluster. A configuração do mecanismo e do host do contêiner, assim como o gerenciamento, torna-se automatizada no OpenShift 4.
Pare, como está?
Isso mesmo, com o advento do OpenShift 4, agora não há mais a necessidade de se conectar a hosts individuais e instalar um mecanismo de contêiner, configurar armazenamento, configurar servidores para pesquisa ou configurar uma rede. A plataforma OpenShift 4 foi completamente redesenhada para usar a
Operator Framework não apenas em termos de aplicativos do usuário final, mas também em termos de operações básicas no nível da plataforma, como implantar imagens, configurar o sistema ou instalar atualizações.
O Kubernetes sempre permite que os usuários gerenciem aplicativos, determinando o estado desejado e usando
Controladores para garantir que o estado real seja o mais próximo possível do estado especificado. Essa
abordagem, usando um determinado estado e um estado real, abre grandes oportunidades, tanto do ponto de vista do desenvolvimento quanto do ponto de vista das operações. Os desenvolvedores podem determinar o estado necessário,
transferi-lo para o operador na forma de um arquivo YAML ou JSON e, em seguida, o operador pode criar a instância de aplicativo necessária no ambiente operacional, enquanto o estado operacional dessa instância corresponderá totalmente ao especificado.
Usando operadores na plataforma, o OpenShift 4 traz esse novo paradigma (usando o conceito de conjunto e estado real) para o gerenciamento do RHEL CoreOS e CRI-O. As tarefas de configuração e versão do sistema operacional e do mecanismo de contêiner são automatizadas usando o chamado
Machine Config Operator (MCO) . O MCO simplifica bastante o trabalho do administrador de cluster, automatizando essencialmente os últimos estágios da instalação, bem como as operações subseqüentes após a instalação (operações do segundo dia). Tudo isso faz do OpenShift 4 uma verdadeira plataforma em nuvem. Vamos nos concentrar nisso um pouco mais tarde.
Lançamento de contêiner
Os usuários tiveram a oportunidade de usar o mecanismo CRI-O na plataforma OpenShift a partir da versão 3.7 no status do Tech Preview e da versão 3.9 no status de Disponibilidade geral (atualmente suportada). Além disso, a Red Hat faz uso
extensivo do
CRI-O para iniciar cargas de trabalho de produção no OpenShift Online desde a versão 3.10. Tudo isso permitiu à equipe que trabalha no CRI-O obter uma vasta experiência no lançamento em massa de contêineres em grandes clusters Kubernetes. Para obter um entendimento básico de como o Kubernetes usa o CRI-O, vamos dar uma olhada na ilustração a seguir, que mostra como a arquitetura funciona.
Fig. 2. Como os contêineres funcionam no cluster KubernetesO CRI-O simplifica a criação de novos hosts de contêiner, sincronizando todo o nível superior ao inicializar novos nós e ao liberar novas versões da plataforma OpenShift. Uma auditoria de plataforma inteira permite atualizações / reversões transacionais e também evita conflitos nas dependências entre o kernel da cauda do contêiner, o mecanismo do contêiner, o Kubelets e o Kubernetes Master. Com o gerenciamento centralizado de todos os componentes da plataforma, com controle e gerenciamento de versão, você sempre pode rastrear um caminho claro do estado A ao estado B. Isso simplifica o processo de atualização, melhora a segurança, melhora os relatórios de desempenho e ajuda a reduzir o custo de atualização e instalação de novas versões.
Demonstração do poder de elementos intercambiáveis
Como mencionado anteriormente, o uso do Machine Config Operator para gerenciar o host e o mecanismo do contêiner no OpenShift 4 fornece um novo nível de automação que antes não era possível na plataforma Kubernetes. Para demonstrar os novos recursos, mostramos como você pode fazer alterações no arquivo crio.conf. Para não ficar confuso com a terminologia, tente se concentrar nos resultados.
Primeiro, vamos criar o que é chamado de configuração de tempo de execução do contêiner - a Configuração do Tempo de Execução do Contêiner. Considere isso um recurso do Kubernetes que representa a configuração do CRI-O. Na realidade, esta é uma versão especializada do que é chamado MachineConfig, que é qualquer configuração implantada em uma máquina RHEL CoreOS dentro de um cluster OpenShift.
Esse recurso personalizado, chamado ContainerRuntimeConfig, foi inventado para facilitar a configuração do CRI-O pelos administradores de cluster. Esta é uma ferramenta suficientemente poderosa que só pode ser aplicada a determinados nós, dependendo das configurações do MachineConfigPool. Considere isso um grupo de máquinas que servem ao mesmo propósito.
Preste atenção nas duas últimas linhas que mudaremos no arquivo /etc/crio/crio.conf. Essas duas linhas são muito semelhantes às linhas no arquivo crio.conf, são elas:
vi ContainerRuntimeConfig.yaml
Conclusão:
apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: set-log-and-pid spec: machineConfigPoolSelector: matchLabels: debug-crio: config-log-and-pid containerRuntimeConfig: pidsLimit: 2048 logLevel: debug
Agora envie esse arquivo para o cluster Kubernetes e verifique se ele realmente foi criado. Observe que a operação é realizada da mesma maneira que com qualquer outro recurso do Kubernetes:
oc create -f ContainerRuntimeConfig.yaml oc get ContainerRuntimeConfig
Conclusão:
NAME AGE set-log-and-pid 22h
Depois de criar o ContainerRuntimeConfig, precisamos modificar um dos MachineConfigPools para fazer o Kubernetes entender que queremos aplicar essa configuração a um grupo específico de máquinas no cluster. Nesse caso, mudaremos MachineConfigPool para os nós principais:
oc edit MachineConfigPool/master
Conclusão (para maior clareza, o ponto principal é deixado):
... metadata: creationTimestamp: 2019-04-10T23:42:28Z generation: 1 labels: debug-crio: config-log-and-pid operator.machineconfiguration.openshift.io/required-for-upgrade: "" ...
Nesse momento, o MCO começa a criar um novo arquivo crio.conf para o cluster. Nesse caso, um arquivo de configuração completo pode ser exibido usando a API do Kubernetes. Lembre-se, ContainerRuntimeConfig é apenas uma versão especializada do MachineConfig, para que possamos ver o resultado observando as linhas em MachineConfigs:
oc get MachineConfigs | grep rendered
Conclusão:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Observe que o arquivo de configuração resultante para os nós principais acabou sendo uma versão mais recente que as configurações originais. Para visualizá-lo, execute o seguinte comando. De passagem, observamos que este é provavelmente um dos melhores scripts de linha única na história do Kubernetes:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Conclusão:
pids_limit = 2048
Agora verifique se a configuração foi aplicada a todos os nós principais. Primeiro, obtemos uma lista de nós no cluster:
oc get node | grep master Output: ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Agora olhe para o arquivo instalado. Você verá que o arquivo foi atualizado com as novas diretivas pid e debug que especificamos no recurso ContainerRuntimeConfig. Elegância em si:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid'
Conclusão:
... pids_limit = 2048 ... log_level = "debug" ...
Todas essas alterações no cluster foram feitas mesmo sem iniciar o SSH. Todo o trabalho foi realizado entrando em contato com o nó principal do Kuberentes. Ou seja, esses novos parâmetros foram configurados apenas nos nós principais. Ao mesmo tempo, os nós de trabalho não foram alterados, o que demonstra as vantagens da metodologia Kubernetes, usando os estados definido e atual, aplicados aos hosts de contêineres e mecanismos de contêineres com elementos intercambiáveis.
O exemplo acima mostra a capacidade de fazer alterações em um pequeno cluster do OpenShift Container Platform 4 com três nós em funcionamento ou em um grande cluster de produção com 3000 nós. De qualquer forma, a quantidade de trabalho será a mesma - e muito pequena - apenas configure o arquivo ContainerRuntimeConfig e altere um rótulo no MachineConfigPool. E você pode fazer isso com qualquer versão da plataforma OpenShift Container Platform 4.X usada pelo Kubernetes ao longo de seu ciclo de vida.
Freqüentemente, as empresas de tecnologia estão se desenvolvendo tão rapidamente que não conseguimos explicar por que escolhemos determinadas tecnologias para os componentes básicos. Os mecanismos de contêiner têm sido historicamente o componente com o qual os usuários interagem diretamente. Como a popularidade dos contêineres começou naturalmente com o advento dos mecanismos de contêiner, os usuários geralmente demonstram interesse neles. Essa é outra razão pela qual a Red Hat optou pelo CRI-O. Os contêineres estão evoluindo, com foco na orquestração hoje, e chegamos à conclusão de que o CRI-O oferece a melhor experiência ao trabalhar com o OpenShift 4.