Plataforma permite agilizar a criação , inclusive na infraestrutura de provedores de serviços em nuvem, em plataformas de virtualização ou em sistemas bare-metal. Para criar uma plataforma verdadeiramente baseada na nuvem, tivemos que assumir um controle rigoroso de todos os elementos utilizados e assim aumentar a confiabilidade de um processo de automação complexo.
A solução óbvia era usar o Red Hat Enterprise Linux CoreOS (uma variante do Red Hat Enterprise Linux) e CRI-O como padrão, e aqui está o porquê...
Como o tema navegação é muito bom para encontrar analogias na hora de explicar o trabalho de Kubernetes e containers, vamos tentar falar sobre os problemas de negócios que CoreOS e CRI-O resolvem, usando um exemplo . Em 1803, Marc Brunel foi encarregado de produzir 100 blocos de cordame para as necessidades da crescente marinha britânica. Um bloco de cordame é um tipo de cordame usado para prender cordas às velas. Até o início do século XIX, esses blocos eram feitos à mão, mas Brunel conseguiu automatizar a produção e passou a produzir blocos padronizados por meio de máquinas-ferramentas. A automação desse processo significava que os blocos resultantes eram essencialmente idênticos, poderiam ser facilmente substituídos se quebrados e poderiam ser produzidos em grandes quantidades.
Agora imagine se Brunel tivesse que fazer esse trabalho para 20 modelos de navios diferentes (versões Kubernetes) e para cinco planetas diferentes com correntes marítimas e ventos completamente diferentes (provedores de nuvem). Além disso, era exigido que todos os navios (clusters OpenShift), independentemente dos planetas em que a navegação é realizada, do ponto de vista dos capitães (operadores que gerenciam a operação dos clusters) se comportassem da mesma forma. Continuando a analogia marítima, os capitães dos navios não se importam com o tipo de blocos de cordame (CRI-O) usados em seus navios - o principal para eles é que esses blocos sejam fortes e confiáveis.
O OpenShift 4, como plataforma em nuvem, enfrenta um desafio comercial muito semelhante. Novos nós devem ser criados no momento da criação do cluster, no caso de falha em um dos nós ou durante o dimensionamento do cluster. Quando um novo nó é criado e inicializado, os componentes críticos do host, incluindo o CRI-O, devem ser configurados adequadamente. Como em qualquer outra produção, as “matérias-primas” devem ser fornecidas no início. No caso dos navios, as matérias-primas são o metal e a madeira. No entanto, no caso de criar um host para implantar contêineres em um cluster OpenShift 4, você precisa ter arquivos de configuração e servidores fornecidos pela API como entrada. O OpenShift fornecerá então o nível necessário de automação ao longo de todo o ciclo de vida, oferecendo o suporte de produto necessário aos usuários finais e, assim, recuperando o investimento 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 versões 4.X) para todos os principais provedores de computação em nuvem, plataformas de virtualização e até mesmo sistemas bare metal. Para fazer isso, os nós devem ser criados com base em elementos intercambiáveis. Quando um cluster requer uma nova versão do Kubernetes, ele também recebe a versão correspondente do CRI-O no CoreOS. Como a versão CRI-O está diretamente vinculada ao Kubernetes, isso simplifica muito qualquer permutação para fins de teste, solução de problemas ou suporte. Além disso, esta abordagem reduz custos para os usuários finais e para a Red Hat.
Esta é uma maneira fundamentalmente nova de pensar sobre clusters Kubernetes e estabelece as bases para o planejamento de alguns novos recursos muito úteis e atraentes. CRI-O (Container Runtime Interface - Open Container Initiative, abreviado como CRI-OCI) acabou sendo a escolha de maior sucesso para a criação em massa de nós necessários para trabalhar com OpenShift. CRI-O substituirá o mecanismo Docker usado anteriormente, oferecendo aos usuários OpenShift – sim, você ouviu direito – um mecanismo de contêiner enfadonho criado especificamente para trabalhar com Kubernetes.
O mundo dos containers abertos
O mundo tem caminhado em direção aos contêineres abertos há muito tempo. Seja no Kubernetes ou em níveis inferiores, resulta em um ecossistema de inovação em todos os níveis.
Tudo começou com a criação da Open Containers Initiative . Nesta fase inicial do trabalho, as especificações dos contêineres foram formadas и . Isso garantiu que as ferramentas pudessem usar um único padrão e um formato unificado para trabalhar com eles. As especificações foram adicionadas posteriormente , permitindo que os usuários compartilhem facilmente .
A comunidade Kubernetes desenvolveu então um padrão único para uma interface conectável, chamado . Graças a isso, os usuários do Kubernetes puderam conectar vários motores para trabalhar com contêineres além do Docker.
Os engenheiros da Red Hat e do Google perceberam a necessidade do mercado de um mecanismo de contêiner que pudesse aceitar solicitações Kubelet através do protocolo CRI e introduziram contêineres que fossem compatíveis com as especificações OCI mencionadas acima. Então . Mas com licença, não falamos que esse material seria dedicado ao CRI-O? Na verdade é, só com o lançamento o projeto foi renomeado como CRI-O.
Fig. 1.
Inovação com CRI-O e CoreOS
Com o lançamento da plataforma OpenShift 4, foi alterado , usado por padrão na plataforma, e o Docker foi substituído pelo CRI-O, oferecendo um ambiente econômico, estável, simples e enfadonho para executar um contêiner que se desenvolve em paralelo com o Kubernetes. Isso simplifica muito o suporte e a configuração do cluster. A configuração do mecanismo e do host do contêiner, bem como seu gerenciamento, torna-se automatizado no OpenShift 4.
Espere, como é isso?
É isso mesmo, com o advento do OpenShift 4, não há mais necessidade de conectar-se a hosts individuais e instalar um mecanismo de contêiner, configurar armazenamento, configurar servidores de pesquisa ou configurar uma rede. A plataforma OpenShift 4 foi completamente redesenhada para usar o não apenas em termos de aplicativos de usuário final, mas também em termos de operações básicas em nível de plataforma, como implantação de imagens, configuração do sistema ou instalação de atualizações.
O Kubernetes sempre permitiu que os usuários gerenciassem aplicativos definindo o estado desejado e usando , para garantir que o estado real corresponda ao estado de destino o mais próximo possível. Esse abre grandes oportunidades tanto do ponto de vista de desenvolvimento quanto de operações. Os desenvolvedores podem definir o estado necessário por ao 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 de produção, e o estado operacional desta instância corresponderá totalmente ao especificado.
Ao utilizar Operadores na plataforma, o OpenShift 4 traz esse novo paradigma (utilizando o conceito de conjunto e estado real) para o gerenciamento do RHEL CoreOS e CRI-O. As tarefas de configuração e gerenciamento de versões do sistema operacional e do mecanismo de contêiner são automatizadas usando o chamado . O MCO simplifica muito o trabalho do administrador do cluster, automatizando essencialmente os últimos estágios da instalação, bem como as operações subsequentes de pós-instalação (operações do segundo dia). Tudo isso faz do OpenShift 4 uma verdadeira plataforma em nuvem. Entraremos nisso um pouco mais tarde.
Executando contêineres
Os usuários tiveram a oportunidade de usar o mecanismo CRI-O na plataforma OpenShift desde a versão 3.7 no status Tech Preview e a partir da versão 3.9 no status Geralmente Disponível (atualmente suportado). Além disso, a Red Hat utiliza massivamente no OpenShift Online desde a versão 3.10. Tudo isso permitiu que a equipe que trabalhava no CRI-O ganhasse ampla experiência no lançamento em massa de contêineres em grandes clusters Kubernetes. Para obter uma compreensão básica de como o Kubernetes usa CRI-O, vejamos a ilustração a seguir, que mostra como a arquitetura funciona.
Arroz. 2. Como funcionam os contêineres em um cluster Kubernetes
O CRI-O simplifica a criação de novos hosts de contêineres, sincronizando todo o nível superior ao inicializar novos nós e ao lançar novas versões da plataforma OpenShift. A revisão de toda a plataforma permite atualizações/reversões transacionais e também evita conflitos nas dependências entre o núcleo final do contêiner, o mecanismo do contêiner, os nós (Kubelets) e o nó mestre do Kubernetes. Ao gerenciar centralmente todos os componentes da plataforma, com controle e versionamento, há sempre um caminho claro do estado A para o 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ções e instalações de novas versões .
Demonstrando o poder dos elementos de substituição
Conforme mencionado anteriormente, usar o Machine Config Operator para gerenciar o host do contêiner e o mecanismo do contêiner no OpenShift 4 fornece um novo nível de automação que não era possível anteriormente na plataforma Kubernetes. Para demonstrar os novos recursos, mostraremos como você pode fazer alterações no arquivo crio.conf. Para evitar ficar confuso com a terminologia, tente focar nos resultados.
Primeiro, vamos criar o que é chamado de configuração de tempo de execução de contêiner - Container Runtime Config. Pense nisso como um recurso do Kubernetes que representa a configuração do CRI-O. Na realidade, é uma versão especializada de algo chamado MachineConfig, que é qualquer configuração implantada em uma máquina RHEL CoreOS como parte de um cluster OpenShift.
Este recurso customizado, chamado ContainerRuntimeConfig, foi criado para facilitar aos administradores de cluster a configuração do CRI-O. Esta ferramenta é poderosa o suficiente para poder ser aplicada apenas a determinados nós, dependendo das configurações do MachineConfigPool. Pense nisso como um grupo de máquinas que servem ao mesmo propósito.
Observe as duas últimas linhas que iremos alterar no arquivo /etc/crio/crio.conf. Essas duas linhas são muito semelhantes às linhas do 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 vamos enviar esse arquivo para o cluster Kubernetes e verificar se ele foi realmente criado. Observe que a operação é exatamente igual a qualquer outro recurso do Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Conclusão:
NAME AGE
set-log-and-pid 22h
Depois de criarmos o ContainerRuntimeConfig, precisamos modificar um dos MachineConfigPools para sinalizar ao Kubernetes que queremos aplicar esta configuração a um grupo específico de máquinas no cluster. Neste caso iremos alterar o MachineConfigPool para os nós mestres:
oc edit MachineConfigPool/master
Conclusão (para maior clareza, resta a essência principal):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Neste ponto, o MCO começa a criar um novo arquivo crio.conf para o cluster. Nesse caso, o arquivo de configuração totalmente finalizado pode ser visualizado usando a API Kubernetes. Lembre-se, ContainerRuntimeConfig é apenas uma versão especializada do MachineConfig, então podemos ver o resultado observando as linhas relevantes 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 mestres era uma versão mais recente que as configurações originais. Para visualizá-lo, execute o seguinte comando. De passagem, notamos que esta é talvez uma das melhores frases curtas da 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 vamos ter certeza de que a configuração foi aplicada a todos os nós mestres. 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 vamos dar uma olhada no arquivo instalado. Você verá que o arquivo foi atualizado com os novos valores das 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 sem sequer executar o SSH. Todo o trabalho foi feito acessando o nó mestre do Kuberentes. Ou seja, esses novos parâmetros foram configurados apenas nos nós mestres. Os nós de trabalho não foram alterados, o que demonstra os benefícios da metodologia Kubernetes de usar estados especificados e reais em relação a hosts de contêineres e motores de contêineres com elementos intercambiáveis.
O exemplo acima mostra a capacidade de fazer alterações em um pequeno cluster OpenShift Container Platform 4 com três nós de produção ou em um enorme cluster de produção com 3000 nós. De qualquer forma, a quantidade de trabalho será a mesma - e muito pequena - basta configurar o arquivo ContainerRuntimeConfig e alterar um rótulo em MachineConfigPool. E você pode fazer isso com qualquer versão do OpenShift Container Platform 4.X executando Kubernetes durante todo o seu ciclo de vida.
Muitas vezes, as empresas tecnológicas evoluem tão rapidamente que não conseguimos explicar porque escolhemos certas tecnologias para os componentes subjacentes. Historicamente, os mecanismos de contêiner têm sido o componente com o qual os usuários interagem diretamente. Como a popularidade dos contêineres começou naturalmente com o advento dos motores de contêineres, os usuários frequentemente demonstram interesse neles. Esta é outra razão pela qual a Red Hat escolheu o CRI-O. Os contêineres estão evoluindo com foco agora na orquestração, e descobrimos que o CRI-O oferece a melhor experiência ao trabalhar com o OpenShift 4.
Fonte: habr.com