Plataforma permite automatizar a criação , incluindo na infraestrutura de provedores de nuvem, em plataformas de virtualização ou em sistemas bare-metal. Para criar uma plataforma verdadeiramente em nuvem, tivemos que controlar rigidamente todos os elementos utilizados e assim aumentar a confiabilidade do complexo processo de automação.
A solução óbvia foi usar como padrão o Red Hat Enterprise Linux CoreOS (uma variante do Red Hat Enterprise Linux) e CRI-O, e aqui está o porquê…
Dado que a temática de navegação é bastante adequada para buscar analogias ao explicar o funcionamento do Kubernetes e dos contêineres, tentaremos descrever os problemas de negócios que o CoreOS e o CRI-O resolvem, usando como exemplo . Em 1803, Mark Brunel foi desafiado a fabricar 100 mil blocos de aparelhagem para atender as necessidades da crescente frota marítima da Grã-Bretanha. Um bloco de aparelhagem é um tipo de equipamento utilizado para fixar cordas a velas. Até o início do século 19, esses blocos eram fabricados manualmente, mas Brunel conseguiu automatizar a produção e começou a fabricar blocos padronizados utilizando máquinas. A automatização desse processo significava que, como resultado, todos os blocos eram praticamente idênticos, podiam ser facilmente substituídos em caso de quebra e podiam ser produzidos em grandes quantidades.
Agora imagine que Brunel tivesse que realizar esse trabalho para 20 modelos diferentes de barcos (versões do Kubernetes) e para cinco planetas distintos 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 pelos quais navegavam, se comportassem da mesma forma do ponto de vista dos capitães (operadores que gerenciam o funcionamento dos clusters). Continuando a analogia marítima, para os capitães dos navios, não importa quais blocos de aparelhagem (CRI-O) são utilizados em seus barcos – o que importa é que esses blocos sejam fortes e confiáveis.
Antes do OpenShift 4, havia um desafio de negócios bastante semelhante. Novos nós devem ser criados no momento da criação do cluster, em caso de falha em um dos nós ou durante a escalabilidade do cluster. Ao criar e inicializar um novo nó, os componentes críticos do host, incluindo o CRI-O, também devem ser configurados adequadamente. Assim como em qualquer outra produção, é necessário fornecer uma 'matéria-prima' no início. No caso de navios, os materiais são metal e madeira. No entanto, ao criar um host para a execução de contêineres no cluster OpenShift 4, é preciso ter arquivos de configuração e servidores API fornecidos. Após isso, o OpenShift garantirá o nível necessário de automação ao longo de todo o ciclo de vida, oferecendo o suporte de produto necessário para os usuários finais e, assim, recuperando os investimentos na plataforma.
O OpenShift 4 foi desenvolvido para permitir atualizações convenientes do sistema durante todo o ciclo de vida da plataforma (para versões 4.X) para todos os principais fornecedores de computação em nuvem, plataformas de virtualização e até mesmo sistemas bare metal. Para isso, os nós devem ser construídos com base em componentes intercambiáveis. Quando o 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 do CRI-O está diretamente vinculada ao Kubernetes, isso simplifica bastante quaisquer rearranjos para fins de teste, solução de problemas ou suporte. Além disso, essa abordagem ajuda a reduzir os custos para os usuários finais e a Red Hat.
Esta é uma nova perspectiva sobre clusters Kubernetes, que estabelece a base para o planejamento de novas funções úteis e atraentes. O CRI-O (Container Runtime Interface - Open Container Initiative, abreviado CRI-OCI) se mostrou a escolha mais apropriada para a criação em massa de nós necessária para o funcionamento do OpenShift. O CRI-O substituirá o motor Docker anteriormente utilizado, oferecendo aos usuários do OpenShift – sim, você não ouviu errado – um motor de contêiner desinteressante, criado especialmente para trabalhar com Kubernetes.
O mundo dos contêineres abertos
O mundo há muito caminha em direção a contêineres abertos. Seja no Kubernetes ou em níveis mais baixos, leva à criação de um ecossistema de inovações em todos os níveis.
Tudo começou com a criação da iniciativa Open Containers Initiative Nesta fase inicial, foram formadas as especificações para a e Isso garantiu que as ferramentas poderiam usar um padrão único e um formato padronizado para trabalhar com elas. Mais tarde, foram adicionadas especificações o que permitiu que os usuários compartilhassem facilmente .
Então, a comunidade Kubernetes desenvolveu um padrão unificado de interface plugável, chamado Graças a isso, os usuários do Kubernetes puderam integrar diferentes mecanismos para trabalhar com contêineres além do Docker.
Engenheiros da Red Hat e do Google perceberam a necessidade existente no mercado por um mecanismo de contêiner que pudesse receber solicitações do Kubelet via protocolo CRI e apresentaram contêineres compatíveis com as especificações OCI mencionadas acima. Assim, Mas espera, dissemos que este material seria dedicado ao CRI-O? Na verdade, sim, apenas com o lançamento da o projeto foi renomeado para CRI-O.
Fig. 1.
Inovações com CRI-O e CoreOS
Com o lançamento da plataforma OpenShift 4, foi alterado usado na plataforma por padrão, e o Docker foi substituído pelo CRI-O, que oferece um ambiente econômico, estável, simples e despreocupado para a execução de contêineres, que se desenvolve em paralelo ao Kubernetes. Isso simplifica significativamente o suporte e a configuração do cluster. A configuração do mecanismo de contêiner e do host, assim como a gestão deles, se torna automatizada dentro do OpenShift 4.
Espere, como assim?
Exatamente assim, com o surgimento do OpenShift 4, agora não é mais necessário se conectar a hosts separados e instalar o mecanismo de contêiner, configurar o armazenamento, ajustar servidores para busca ou configurar a rede. A plataforma OpenShift 4 foi completamente reformulada para utilização do não apenas do ponto de vista das aplicações dos usuários finais, mas também do ponto de vista das operações básicas em nível de plataforma, como a implantação de imagens, configuração do sistema ou instalação de atualizações.
O Kubernetes sempre permitiu que os usuários gerenciassem aplicações definindo o estado desejado e utilizando , para garantir que o estado real corresponda o máximo possível ao estado definido. Essa abre grandes oportunidades tanto do ponto de vista de desenvolvimento quanto do ponto de vista de operações. Os desenvolvedores podem definir o estado necessário, para o operador na forma de um arquivo YAML ou JSON, e então o operador poderá criar no ambiente operacional a instância necessária da aplicação, com o estado de operação dessa instância correspondendo exatamente ao estado definido.
Usando operadores (Operators) na plataforma, o OpenShift 4 traz essa nova paradigma (usando o conceito de estado definido 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êineres são automatizadas através do chamado . O MCO simplifica significativamente o trabalho do administrador do cluster, automatizando essencialmente as etapas finais da instalação, bem como as operações subsequentes após a instalação (day two operations). Tudo isso torna o OpenShift 4 uma verdadeira plataforma de nuvem. Vamos abordar isso mais adiante.
Execução de contêineres
Os usuários tiveram a possibilidade de usar o mecanismo CRI-O na plataforma OpenShift a partir da versão 3.7 em status de Tech Preview e a partir da versão 3.9 em status de Generally Available (atualmente suportado). Além disso, a Red Hat utiliza amplamente no OpenShift Online a partir da versão 3.10. Tudo isso permitiu que a equipe trabalhando no CRI-O adquirisse uma enorme experiência em grande escala no lançamento de contêineres em grandes clusters Kubernetes. Para ter uma visão básica de como o Kubernetes utiliza o CRI-O, vamos considerar a seguinte ilustração, que mostra o princípio de funcionamento da arquitetura.
Fig. 2. Como os contêineres funcionam em um cluster Kubernetes
CRI-O simplifica a criação de novos hosts de contêiner ao sincronizar todo o nível superior durante a inicialização de novos nós e ao lançar novas versões da plataforma OpenShift. A revisão de toda a plataforma como um todo permite a realização de atualizações / reversões transacionais, além de prevenir bloqueios mútuos nas dependências entre o núcleo do host de contêiner, o mecanismo de contêiner, os nós (Kubelets) e o nó mestre do Kubernetes. Com a gestão centralizada de todos os componentes da plataforma, com controle e gerenciamento de versões, é possível rastrear sempre um caminho claro do estado A para o estado B. Isso simplifica o processo de atualizações, aumenta a segurança, melhora o relatório de desempenho e ajuda a reduzir os custos de atualização e instalação de novas versões.
Demonstração do poder dos elementos intercambiáveis
Como mencionado anteriormente, o uso do Machine Config Operator para gerenciar o host de contêiner e o mecanismo de contêiner no OpenShift 4 proporciona um novo nível de automação que não era possível na plataforma Kubernetes anteriormente. Para demonstrar novas capacidades, mostraremos como você poderia fazer alterações no arquivo crio.conf. Para não se confundir com a terminologia, tente se concentrar nos resultados.
Primeiro, vamos criar o que é chamado de configuração do ambiente de execução do contêiner – Container Runtime Config. Considere que isso é um recurso Kubernetes que representa a configuração para o CRI-O. Na verdade, é uma versão especializada do que é chamado de MachineConfig, que representa qualquer configuração que é implantada em uma máquina RHEL CoreOS dentro do cluster OpenShift.
Este recurso personalizado, chamado ContainerRuntimeConfig, foi concebido para facilitar a configuração do CRI-O para administradores de cluster. É uma ferramenta poderosa que pode ser aplicada apenas a determinados nós, dependendo das configurações do MachineConfigPool. Considere isso como um grupo de máquinas que servem ao mesmo propósito.
Preste atenção nas duas últimas linhas que vamos alterar no arquivo /etc/crio/crio.conf. Essas duas linhas são muito semelhantes às linhas no arquivo crio.conf, que são:
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 este arquivo para o cluster Kubernetes e verificar se ele realmente foi criado. Note que o trabalho é realizado exatamente da mesma forma que com qualquer outro recurso do Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Conclusão:
NOME IDADE
set-log-and-pid 22h
Depois de criarmos o ContainerRuntimeConfig, precisamos alterar um dos MachineConfigPools para informar ao Kubernetes que queremos aplicar essa configuração a um grupo específico de máquinas no cluster. Neste caso, vamos modificar o MachineConfigPool para os nós master:
oc edit MachineConfigPool/master
Saída (para clareza, a essência principal foi preservada):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Neste momento, o MCO começa a criar um novo arquivo crio.conf para o cluster. O arquivo de configuração completamente pronto pode ser visualizado através da API do Kubernetes. Lembre-se, o ContainerRuntimeConfig é apenas uma versão especializada do MachineConfig, por isso podemos ver o resultado olhando as linhas necessárias nos 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
Note que o arquivo de configurações obtido para os nós master é de uma versão mais nova do que as configurações originais. Para visualizá-lo, execute o seguinte comando. Observamos que este é, possivelmente, um dos melhores scripts em uma única linha 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 vamos garantir que a configuração foi aplicada a todos os nós master. Primeiro, vamos obter a lista de nós no cluster:
oc get node | grep master
Saída:
ip-10-0-135-153.us-east-2.compute.internal Pronto master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Pronto master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Pronto master 23h v1.12.4+509916ce1
Agora vamos visualizar o arquivo instalado. Você verá que o arquivo foi atualizado com os novos valores das diretivas pid e debug que especificamos no recurso ContainerRuntimeConfig. A própria elegância:
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 mudanças no cluster foram feitas mesmo sem a execução do SSH. Todo o trabalho foi realizado por meio de chamadas ao nó mestre do Kubernetes. 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 as vantagens da metodologia Kubernetes usando estados desejados e atuais relacionados a hosts de contêineres e mecanismos de contêiner com elementos intercambiáveis.
O exemplo acima mostra a possibilidade de fazer alterações em um pequeno cluster OpenShift Container Platform 4 com três nós de trabalho ou em um enorme cluster de produção com 3000 nós. Em qualquer caso, o volume de trabalho será o mesmo - e bastante reduzido - basta configurar o arquivo ContainerRuntimeConfig e alterar um rótulo (label) no MachineConfigPool. E você pode fazer isso com qualquer versão da plataforma OpenShift Container Platform 4.X usada no Kubernetes ao longo de seu ciclo de vida.
Com frequência, as empresas de tecnologia crescem tão rapidamente que não conseguimos explicar por que escolhemos determinadas tecnologias para componentes básicos. Os mecanismos de contêiner historicamente foram o componente com o qual os usuários interagem diretamente. À medida que a popularidade dos contêineres começou com a introdução dos mecanismos de contêiner, os usuários frequentemente demonstram interesse por eles. Essa é mais uma razão pela qual a Red Hat optou pelo CRI-O. Os contêineres estão evoluindo, e hoje o foco principal é a orquestração; chegamos à conclusão de que o CRI-O oferece a melhor experiência ao trabalhar com o OpenShift 4.
Fonte: habr.com
