Plataforma permite axilizar a creación , incluso na infraestrutura dos provedores de servizos na nube, en plataformas de virtualización ou en sistemas bare-metal. Para crear unha plataforma verdadeiramente baseada na nube, tivemos que levar un control estrito de todos os elementos utilizados e aumentar así a fiabilidade dun proceso de automatización complexo.
A solución obvia foi usar Red Hat Enterprise Linux CoreOS (unha variante de Red Hat Enterprise Linux) e CRI-O como estándar, e aquí tes por que...
Dado que o tema da vela é moi bo para atopar analoxías á hora de explicar o traballo de Kubernetes e os contedores, intentemos falar dos problemas empresariais que solucionan CoreOS e CRI-O, usando un exemplo. . En 1803, Marc Brunel encargouse de producir 100 bloques de aparello para as necesidades da crecente mariña británica. Un bloque de aparello é un tipo de aparello que se usa para unir cordas ás velas. Ata principios do século XIX, estes bloques facíanse a man, pero Brunel conseguiu automatizar a produción e comezou a producir bloques estandarizados mediante máquinas ferramenta. A automatización deste proceso significaba que os bloques resultantes eran esencialmente idénticos, podían ser facilmente substituídos se se rompían e podían producirse en grandes cantidades.
Agora imaxina se Brunel tivese que facer este traballo para 20 modelos de barcos diferentes (versións Kubernetes) e para cinco planetas diferentes con correntes mariñas e ventos completamente diferentes (provedores de nubes). Ademais, esixíase que todas as naves (clusters OpenShift), independentemente dos planetas nos que se realice a navegación, desde o punto de vista dos capitáns (operadores que xestionan o funcionamento dos clusters) se comportasen do mesmo xeito. Para continuar coa analoxía marítima, aos capitáns de barcos non lles importa nada que tipo de bloques de aparello (CRI-O) se utilicen nos seus barcos; o principal para eles é que estes bloques son fortes e fiables.
OpenShift 4, como plataforma na nube, enfróntase a un desafío empresarial moi similar. Deben crearse novos nodos no momento da creación do clúster, no caso de producirse un fallo nun dos nodos ou ao escalar o clúster. Cando se crea e inicializa un novo nodo, os compoñentes críticos do host, incluído CRI-O, deben configurarse en consecuencia. Como en calquera outra produción, as "materias primas" deben ser subministradas ao principio. No caso dos buques, as materias primas son o metal e a madeira. Non obstante, no caso de crear un host para a implantación de contedores nun clúster OpenShift 4, cómpre ter ficheiros de configuración e servidores proporcionados pola API como entrada. OpenShift proporcionará entón o nivel de automatización necesario ao longo de todo o ciclo de vida, ofrecendo o soporte de produto necesario aos usuarios finais e recuperando así o investimento na plataforma.
OpenShift 4 creouse de xeito que ofrece a posibilidade de actualizar convenientemente o sistema ao longo de todo o ciclo de vida da plataforma (para as versións 4.X) para todos os principais provedores de computación en nube, plataformas de virtualización e incluso sistemas bare metal. Para iso, os nodos deben crearse a partir de elementos intercambiables. Cando un clúster require unha nova versión de Kubernetes, tamén recibe a versión correspondente de CRI-O en CoreOS. Dado que a versión de CRI-O está ligada directamente a Kubernetes, isto simplifica moito as permutacións para probas, resolución de problemas ou fins de asistencia. Ademais, este enfoque reduce os custos para os usuarios finais e Red Hat.
Esta é unha forma fundamentalmente nova de pensar nos clústeres de Kubernetes e senta as bases para planificar algunhas funcións novas moi útiles e convincentes. CRI-O (Container Runtime Interface - Open Container Initiative, abreviado CRI-OCI) resultou ser a opción máis exitosa para a creación masiva de nodos que é necesario para traballar con OpenShift. CRI-O substituirá o motor Docker usado anteriormente, ofrecendo aos usuarios de OpenShift – si, escoitaches ben – un aburrido motor de contedores creado especificamente para traballar con Kubernetes.
O mundo dos envases abertos
O mundo leva moito tempo camiñando cara aos contedores abertos. Xa sexa en Kubernetes ou en niveis inferiores, resulta en un ecosistema de innovación a todos los niveles.
Todo comezou coa creación da Open Containers Initiative . Nesta fase inicial do traballo, formáronse as especificacións dos contedores и . Isto garantiu que as ferramentas puidesen utilizar un único estándar e un formato unificado para traballar con eles. Máis tarde engadíronse especificacións , permitindo aos usuarios compartir facilmente .
A comunidade de Kubernetes desenvolveu entón un único estándar para unha interface conectable, chamado . Grazas a isto, os usuarios de Kubernetes puideron conectar varios motores para traballar con contedores ademais de Docker.
Os enxeñeiros de Red Hat e Google viron a necesidade do mercado dun motor de contedores que puidese aceptar solicitudes de Kubelet a través do protocolo CRI e introduciron contedores compatibles coas especificacións OCI mencionadas anteriormente. Entón . Pero desculpe, non dixemos que este material estaría dedicado ao CRI-O? En realidade é así, só co lanzamento o proxecto pasou a chamarse CRI-O.
Fig. 1.
Innovación con CRI-O e CoreOS
Co lanzamento da plataforma OpenShift 4, cambiouse , usado por defecto na plataforma, e Docker foi substituído por CRI-O, que ofrece un ambiente rendible, estable, sinxelo e aburrido para executar un contedor que se desenvolve en paralelo con Kubernetes. Isto simplifica moito o soporte e a configuración do clúster. A configuración do motor de contedores e do host, así como a súa xestión, automatízase dentro de OpenShift 4.
Espera, como é isto?
Así é, coa chegada de OpenShift 4, xa non é necesario conectarse a hosts individuais e instalar un motor de contedores, configurar o almacenamento, configurar servidores de busca ou configurar unha rede. A plataforma OpenShift 4 foi completamente redeseñado para usar non só no que se refire ás aplicacións do usuario final, senón tamén ás operacións básicas a nivel de plataforma, como a implantación de imaxes, a configuración do sistema ou a instalación de actualizacións.
Kubernetes sempre permitiu aos usuarios xestionar aplicacións definindo o estado desexado e utilizando , para asegurarse de que o estado real coincida o máis preto posible co estado de destino. Isto abre grandes oportunidades tanto desde a perspectiva de desenvolvemento como de operacións. Os desenvolvedores poden definir o estado necesario mediante ao operador en forma de ficheiro YAML ou JSON e, a continuación, o operador pode crear a instancia de aplicación requirida no ambiente de produción e o estado operativo desta instancia corresponderá totalmente ao especificado.
Ao usar Operadores na plataforma, OpenShift 4 achega este novo paradigma (usando o concepto de conxunto e estado real) á xestión de RHEL CoreOS e CRI-O. As tarefas de configuración e xestión de versións do sistema operativo e do motor de contedores automatízanse mediante o chamado . MCO simplifica moito o traballo do administrador do clúster, automatizando esencialmente as últimas etapas da instalación, así como as operacións posteriores á instalación (operacións do segundo día). Todo isto fai que OpenShift 4 sexa unha verdadeira plataforma na nube. Entraremos nisto un pouco máis tarde.
Execución de contedores
Os usuarios tiveron a oportunidade de usar o motor CRI-O na plataforma OpenShift desde a versión 3.7 no estado Tech Preview e desde a versión 3.9 no estado Xeralmente Dispoñible (actualmente compatible). Ademais, Red Hat úsao masivamente en OpenShift Online desde a versión 3.10. Todo isto permitiu ao equipo que traballa en CRI-O adquirir unha ampla experiencia no lanzamento masivo de contedores en grandes clústeres de Kubernetes. Para obter unha comprensión básica de como Kubernetes usa CRI-O, vexamos a seguinte ilustración, que mostra como funciona a arquitectura.
Arroz. 2. Como funcionan os contedores nun clúster de Kubernetes
CRI-O simplifica a creación de novos hosts de contedores sincronizando todo o nivel superior ao inicializar novos nodos e ao lanzar novas versións da plataforma OpenShift. A revisión de toda a plataforma permite actualizacións/retrocesos transaccionais e tamén evita os bloqueos nas dependencias entre o núcleo de cola do contedor, o motor de contedores, os nós (Kubelets) e o nodo mestre de Kubernetes. Ao xestionar de forma centralizada todos os compoñentes da plataforma, con control e versións, sempre hai un camiño claro do estado A ao estado B. Isto simplifica o proceso de actualización, mellora a seguridade, mellora os informes de rendemento e axuda a reducir o custo das actualizacións e instalacións das novas versións. .
Demostración do poder dos elementos de substitución
Como se mencionou anteriormente, o uso do operador de configuración da máquina para xestionar o host de contedores e o motor de contedores en OpenShift 4 proporciona un novo nivel de automatización que antes non era posible na plataforma Kubernetes. Para mostrar as novas funcións, mostraremos como podes facer cambios no ficheiro crio.conf. Para evitar confundirse coa terminoloxía, tenta centrarse nos resultados.
En primeiro lugar, imos crear o que se chama unha configuración de tempo de execución do contedor - Container Runtime Config. Pense nel como un recurso de Kubernetes que representa a configuración de CRI-O. En realidade, é unha versión especializada de algo chamado MachineConfig, que é calquera configuración que se despregue nunha máquina RHEL CoreOS como parte dun clúster OpenShift.
Este recurso personalizado, chamado ContainerRuntimeConfig, creouse para facilitar aos administradores do clúster a configuración de CRI-O. Esta ferramenta é o suficientemente potente que só se pode aplicar a certos nodos dependendo da configuración de MachineConfigPool. Pense nel como un grupo de máquinas que serven para o mesmo propósito.
Fíxate nas dúas últimas liñas que imos cambiar no ficheiro /etc/crio/crio.conf. Estas dúas liñas son moi similares ás liñas do ficheiro crio.conf, son:
vi ContainerRuntimeConfig.yaml
Conclusión:
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 imos enviar este ficheiro ao clúster de Kubernetes e comprobar que se creou realmente. Ten en conta que a operación é exactamente a mesma que con calquera outro recurso de Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Conclusión:
NAME AGE
set-log-and-pid 22h
Unha vez que creamos o ContainerRuntimeConfig, necesitamos modificar un dos MachineConfigPools para indicarlle a Kubernetes que queremos aplicar esta configuración a un grupo específico de máquinas do clúster. Neste caso cambiaremos o MachineConfigPool para os nodos mestres:
oc edit MachineConfigPool/master
Conclusión (para claridade, déixase a esencia 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 punto, MCO comeza a crear un novo ficheiro crio.conf para o clúster. Neste caso, o ficheiro de configuración completamente rematado pódese ver mediante a API de Kubernetes. Lembre, ContainerRuntimeConfig é só unha versión especializada de MachineConfig, polo que podemos ver o resultado mirando as liñas relevantes en MachineConfigs:
oc get MachineConfigs | grep rendered
Conclusión:
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
Teña en conta que o ficheiro de configuración resultante para os nodos mestres era unha versión máis nova que as configuracións orixinais. Para velo, execute o seguinte comando. De paso, observamos que este é quizais un dos mellores one-liners da historia de 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
Conclusión:
pids_limit = 2048
Agora asegurémonos de que a configuración se aplicou a todos os nodos mestres. Primeiro obtemos unha lista de nodos do clúster:
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 vexamos o ficheiro instalado. Verá que o ficheiro foi actualizado cos novos valores para as directivas pid e depuración que especificamos no recurso ContainerRuntimeConfig. Elegancia en si:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Conclusión:
...
pids_limit = 2048
...
log_level = "debug"
...
Todos estes cambios no clúster fixéronse sen sequera executar SSH. Todo o traballo realizouse accedendo ao nodo mestre Kuberentes. É dicir, estes novos parámetros configuráronse só nos nodos mestres. Os nodos de traballo non cambiaron, o que demostra os beneficios da metodoloxía Kubernetes de usar estados especificados e reais en relación aos hosts de contedores e motores de contedores con elementos intercambiables.
O exemplo anterior mostra a capacidade de facer cambios nun pequeno clúster OpenShift Container Platform 4 con tres nodos de produción ou nun enorme clúster de produción con 3000 nodos. En calquera caso, a cantidade de traballo será a mesma - e moi pequena - basta con configurar o ficheiro ContainerRuntimeConfig e cambiar unha etiqueta en MachineConfigPool. E podes facelo con calquera versión de OpenShift Container Platform 4.X que execute Kubernetes ao longo do seu ciclo de vida.
Moitas veces, as empresas tecnolóxicas evolucionan tan rápido que non somos capaces de explicar por que escollemos certas tecnoloxías para os compoñentes subxacentes. Os motores de contedores foron historicamente o compoñente co que os usuarios interactúan directamente. Dado que a popularidade dos contedores comezou naturalmente coa chegada dos motores de contedores, os usuarios adoitan mostrar interese por eles. Esta é outra razón pola que Red Hat elixiu CRI-O. Os contedores están a evolucionar centrándose agora na orquestración, e descubrimos que CRI-O ofrece a mellor experiencia ao traballar con OpenShift 4.
Fonte: www.habr.com