El desarrollo se puede comparar con una imagen en la que el artista es un desarrollador líder. Creando una elegante aplicación de microservicio - con las creaciones de los mejores arquitectos - modernistas. Pero para poner en marcha el proceso y dejar la oportunidad de elegir: el arte. En el primer artículo de la serie, queremos hablar sobre cómo se crearon y ejecutaron el servicio IBM Kubernetes y el servicio en la nube IBM Managed OpenShift, y cómo puede implementar y probar su clúster Kubernetes en la nube de IBM de forma gratuita.
La nube de IBM ha ido ganando funcionalidad en los últimos diez años. Todo comenzó con la construcción de infraestructuras compartidas para dar servicio a grandes corporaciones, luego con máquinas virtuales y físicas basadas en centros de datos SoftLayer, luego hubo la construcción de cinco años de PaaS (basado en tiempos de ejecución de Cloud Foundry) y la evolución de una gran cantidad de servicios. El equipo de desarrollo de Moscú también participó en la creación de parte de los servicios. Pero hoy no se trata de servicios, sino de qué son los kubernetes administrados y el OpenShift administrado y cómo funciona en la nube de IBM. No se pueden contar muchos detalles, ya que el proyecto es interno, pero es posible abrir una cierta cortina.
Qué es kubernetes y cómo se gestiona kubernetes / openshift de forma diferente a una instalación local
Kubernetes se posicionó inicialmente como una plataforma de código abierto para administrar aplicaciones y servicios en contenedores. Las tareas principales de kubernetes son (me iré sin traducción, para no romper la terminología):
- Servicio de descubrimiento y equilibrio de carga
- Orquestación de almacenamiento
- Lanzamientos y retrocesos automatizados
- Embalaje automático
- Autocuración
- Secreto y gestión de configuración
En general, kubernetes hace un excelente trabajo en todas estas tareas. Por otro lado, kubernetes comenzó a posicionarse como una base de datos para almacenar configuraciones de aplicaciones o una herramienta API para administrar sus componentes (especialmente relevante en el contexto del desarrollo de operadores).
Una de las ventajas de kubernetes es que puede ejecutar aplicaciones en contenedores tanto en sus recursos informáticos como en la nube. En el caso de los recursos en la nube, muchos proveedores de la nube brindan la capacidad de usar recursos informáticos para ejecutar aplicaciones y administrar completamente los clústeres:
- despliegue de clúster
- Establecer la disponibilidad y distribución de la red
- instalación de actualizaciones y fixpacks
- Configurar un clúster para aumentar la tolerancia a fallas y la seguridad (más en el artículo)
- ...
Si trabaja con kubernetes administrados en cualquier nube, entonces, por supuesto, está limitado en una serie de acciones. Por ejemplo, generalmente se admiten varias versiones de kubernetes y es poco probable que pueda usar versiones de kubernetes que no hayan sido compatibles durante mucho tiempo. La principal ventaja es, sin duda, que no es su equipo el que administra los clústeres, lo que reduce el tiempo requerido para desarrollar aplicaciones. Por supuesto, los kubernetes administrados y el OpenShift administrado no se pueden usar en todas las organizaciones y para ningún tipo de aplicación, pero hay una amplia gama de tareas que son excelentes para la computación en las nubes.
Arquitectura de la nube
Dentro de la empresa, el proyecto IBM Managed Kubernetes y el proyecto IBM Managed OpenShift se denominan proyecto Armada. El proyecto comenzó con un centro de datos, pero ahora está disponible en 60 centros de datos en la nube en 6 regiones diferentes. Para describir cómo se escala la nube, utilizaré dos términos: concentradores y radios. Todo el proyecto Armada se basa en kubernetes, lo que significa que sus grupos están controlados por un panel de control que se ejecuta en kubernetes. Tan pronto como el panel de control no tenga suficientes recursos para administrar el conjunto necesario de clústeres, despliega radios adicionales. Estos radios continuarán siendo responsables de administrar los clústeres en una región específica.
El panel de control consta de más de 1,500 implementaciones y está ubicado en 60 grupos de kubernetes. Todo esto es necesario para administrar más de 15,000 clústeres de nuestros clientes (sin incluir los clústeres gratuitos de prueba que se implementan en el mismo trabajador).
Para crear IKS y OpenShift administrado, el equipo utilizó el modelo OpenSource internamente. La mayoría de los empleados de IBM tienen acceso a la mayoría de los repositorios de Armada y pueden crear sus propios RP para integrar sus servicios. Como parte del trabajo de servicio, también se desarrolló una gran cantidad de herramientas de CI / CD, que se integraron en el proyecto Razee. En el verano de 2019, IBM subió todos los logros del proyecto Razee a OpenSource.
En general, la arquitectura para IKS y OpenShift administrado es la siguiente:
Cuando trabaja con IBM Cloud CLI y solicita la creación de un clúster, de hecho, sus solicitudes van a la API de Armada, luego el panel de control determina la disponibilidad de radios e inicia la creación del número requerido de trabajadores en las regiones que especifique. Toda la infraestructura para los trabajadores se proporciona utilizando la Infraestructura de la Nube de IBM (también conocida como Soflayer), de hecho, se utilizan las mismas instancias virtuales y hosts básicos, que están disponibles en la sección "Computar" del catálogo de servicios en la nube. Después de un tiempo, recibirá un token de autorización y podrá comenzar a implementar sus aplicaciones.
Dado que OpenShift y Kubernetes difieren en sus capacidades y hoja de ruta de desarrollo, la pila de tecnología subyacente es correspondientemente diferente:
¿Cómo se garantiza la seguridad?
Podemos hablar sobre el proyecto Armada durante mucho tiempo tanto desde el punto de vista técnico como desde el de marketing. Pero antes que nada, al elegir un proveedor en la nube que proporcione kubernetes administrados, todos hacen la misma pregunta: ¿cómo garantiza y garantiza el proveedor la seguridad y la tolerancia a fallas de mis aplicaciones? Es imposible evaluar el rendimiento, la conveniencia y el nivel de soporte de servicio sin recibir una respuesta a esta pregunta. Como gerente de desarrollo, durante el desarrollo de cualquier proyecto importante, dibujo un mapa de las amenazas. Es necesario introducir todas las opciones de piratería posibles y proteger su infraestructura, aplicaciones y datos. Para hablar sobre la seguridad del clúster kubernetes, debe describir los siguientes puntos:
- seguridad de la propia infraestructura y centros de datos
- acceso a la API de Kubernetes y etcd
- maestro de seguridad y nodos de trabajo
- seguridad de red
- seguridad de almacenamiento persistente
- monitoreo y registro
- seguridad de contenedores e imágenes de contenedores
Ahora, lo primero es lo primero:
Seguridad de la propia infraestructura y centros de datos.
No importa cómo nos gustaría desconectarnos por completo del hardware y el mantenimiento del relleno de hardware de los sistemas de TI, de hecho, debemos asegurarnos de que el proveedor de servicios cubra completamente nuestra parte trasera y confirmar esto documentado con la ayuda de certificaciones industriales y de la industria, y si es necesario con la ayuda de informes sobre realización de auditorías Este aspecto fue tenido en cuenta por el equipo de IBM con toda la seriedad posible y toda la información necesaria fue recopilada y presentada en un solo lugar ( https://www.ibm.com/cloud/compliance )
Acceda a la API de Kubernetes y etcd
Para acceder a la API y los datos de Kubernetes en etcd, debe pasar por tres niveles de autorización. Cada token de autorización emitido está asociado con tokens de autenticación, datos de autorización de clúster (RBAC) y el controlador de Admisión (consulte el diagrama a continuación).
Dado que los asistentes se configuran de manera centralizada utilizando radios, esto significa que no puede cambiar la configuración del asistente, los asistentes mismos ni siquiera se encuentran en su cuenta en la nube y no son visibles en la lista de sus dispositivos (a diferencia de los trabajadores). Todos los cambios de configuración solo pueden realizarse dentro de ciertas capacidades. Por un lado, esto es una limitación, pero debido a esta limitación, los ciberdelincuentes tampoco tendrán acceso a sus asistentes, además de esto no hay factor de error humano, no hay riesgo de usar versiones incompatibles de componentes de kubernetes, y se facilita todo el proceso de administración del clúster. En general, podemos decir que IBM es responsable de garantizar la tolerancia a fallos y la configuración correcta del maestro de kubernetes. Si su proyecto tiene requisitos estrictos para usar ciertas versiones de componentes, entonces en su lugar no miraría los kubernetes administrados en absoluto y usaría mi propia instalación.
Maestro de seguridad y nodos de trabajo
Para garantizar la seguridad de los trabajadores y el maestro de los nodos, utilizamos túneles VPN encriptados entre los nodos informáticos, y el usuario tiene la oportunidad de ordenar a un trabajador con discos duros encriptados. También usamos Application Armor para restringir el acceso de la aplicación a los recursos a nivel del sistema operativo. Application Armor es una extensión del kernel de Linux para configurar el acceso a recursos para cada aplicación.
Al crear un clúster, después de elegir la configuración que más le convenga, se crearán servidores virtuales o de metal desnudo para usted, en los que se instalarán los componentes para el trabajo de sus trabajadores. El usuario tiene acceso al sistema operativo del trabajador, pero solo cuando está conectado a través de una VPN de administración, que puede ser útil para la resolución de problemas, así como para actualizar el sistema operativo del trabajador. No hay acceso IP público a través de ssh, para obtener ssh dentro del contenedor, debe usar kubectl exec, esta conexión se realizará a través del túnel OpenVPN.
Seguridad de red
En kubernetes gestionados y openshift, se utiliza un complemento de red Calico como solución de virtualización de red. La seguridad de la red se logra a través de políticas de red Kubernetes y Calico preconfiguradas. Sus trabajadores pueden estar en la misma VLAN que toda su otra infraestructura en el mismo centro de datos, como máquinas virtuales ordinarias y servidores de metal desnudo, así como aplicaciones de red y sistemas de almacenamiento, y gracias a los sistemas calico ubicados fuera de su clúster, podrá comunicarse a través de una red privada con sus implementaciones.
Cuando se crea un clúster con una VLAN pública, el panel de control crea un recurso HostEndpoint con la ibm.role: worker_public para cada trabajador y sus interfaces de red externas. Para proteger las interfaces de red externas, el panel de control aplicará todas las políticas predeterminadas de Calico a todos los puntos finales con la ibm.role: worker_public .
Las políticas predeterminadas de Calico permiten todo el tráfico saliente y permiten el tráfico entrante de Internet a ciertos componentes (Kubernetes NodePort, LoadBalancer y el servicio Ingress). El resto del tráfico está bloqueado. Las políticas predeterminadas no se aplican al tráfico dentro del clúster (interacción entre pods)
Seguridad de almacenamiento persistente
Por seguridad en el nivel de persistencia, se utilizan cifrado y autorización de clave. Actualmente disponible para IKS:
- NFS clásico
- Almacenamiento en bloque clásico (iSCSI)
- VP bloque de almacenamiento
- Ibm almacenamiento de objetos en la nube
- SDS basado en Porworx (utiliza unidades locales de sus propios trabajadores)
Monitoreo y registro
Puede utilizar IBM Cloud Monitoring o una solución de Sysdig para monitorear IKS. Naturalmente, Prometeo no estaba sin él. OpenShift administrado utiliza herramientas de monitoreo integradas.
Con los registros en sí, las cosas son más complicadas. Es necesario recopilar registros de niveles completamente diferentes, utilizamos una gran cantidad de soluciones propias y de código abierto. Recopilamos y almacenamos los siguientes registros:
- Registros del contenedor en sí (STDOUT, STDERR)
- Registros de aplicación (si se especifica la ruta a ellos)
- Registros desde el nodo de trabajo
- Registros API de Kubernetes
- Registros de entrada
- Registros de todos los componentes del sistema Kubernetes (espacio de nombres del sistema kube)
Para controlar los registros, está disponible un servicio IBM Cloud Log Analysis con LogDNA separado, que le permite mostrar todos los registros en una consola común y analizarlos retrospectivamente o en tiempo real, dependiendo de la tarifa. Puede crear una instancia por separado en cada una de las 6 regiones y luego usarla para recopilar los registros de su clúster Kubernetes y otra infraestructura en su cuenta. Para conectar este servicio a su clúster, debe colocar un pod con el agente LogDNA siguiendo instrucciones simples, y todos los registros se enviarán al repositorio LogDNA, luego, según el plan elegido, estarán disponibles para un análisis posterior durante un cierto período.
Para analizar las actividades dentro de sus servicios en la nube, incluidos los inicios de sesión y mucho más, Activity Tracker con LogDNA está disponible: le permite realizar un seguimiento de diversas acciones en sus servicios.
Como herramienta de monitoreo adicional, puede configurar IBM Cloud Monitoring con Sysdig en su clúster: está disponible en las 6 regiones, lo que le permitirá monitorear muchas métricas en su clúster en tiempo real y usar las integraciones integradas con muchos entornos comunes que se ejecutan en contenedores. Además, puede configurar la reacción a los eventos con la posibilidad de notificaciones a través de holgura, correo electrónico, PagerDuty, WebHook, etc.
Contenedor y seguridad de imagen de contenedor
La compañía tiene su propia opinión sobre lo que se incluye en DevOps. Si alguien está interesado, puede leer más sobre esto en el método de IBM Garage . Comprender qué DevSecOps también se forma en muchas empresas y se aplica en la práctica. Para comprender en qué etapas pasa una imagen de Docker para convertirse en un contenedor de Docker, eche un vistazo a la siguiente figura.
En la nube de IBM, es posible utilizar el registro Docker como un servicio. Al enviar una imagen a este registro, la imagen de la ventana acoplable está firmada. Por parte del nodo de trabajo, se instala el complemento, que es responsable de verificar la integridad y el cumplimiento de las políticas de seguridad: Asesor de vulnerabilidades. Usando estas políticas, puede, por ejemplo, limitar el círculo de registro, desde donde es posible descargar imágenes acoplables.
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
El Asesor de vulnerabilidades trabaja con contenedores en ejecución, escaneándolos periódicamente y detectando automáticamente los paquetes instalados. Las imágenes de Docker con vulnerabilidades potenciales están marcadas como peligrosas para su uso y proporcionan información detallada sobre las vulnerabilidades encontradas.
El asesor de seguridad es el centro para gestionar todas las vulnerabilidades de su aplicación. Permite la capacidad de trabajar con problemas y solucionarlos. Funciona tanto con los resultados del Asesor de vulnerabilidades como con el clúster en sí mismo, advirtiendo oportunamente sobre la necesidad de actualizar un componente en particular.
Ejemplo de registro e implementación de un clúster gestionado de kubernetes
Puede implementar y probar su clúster Kubernetes administrado en la nube de IBM de forma totalmente gratuita:
- Regístrese en la nube de IBM: https://ibm.biz/rucloud (debe confirmar su dirección de correo electrónico, no necesita agregar datos de tarjeta de crédito en esta etapa)
- Para usar el servicio IKS, puede transferir su cuenta a una pagada (al hacer clic en Actualizar e ingresar los datos de su tarjeta bancaria, recibirá $ 200 en la cuenta). O especialmente para los lectores de Habr, puede obtener un cupón para cambiar su cuenta al modo de prueba; esto le permitirá implementar un clúster mínimo de forma gratuita durante 30 días. Después de este período, el clúster se puede volver a crear y continuar con las pruebas. Puede solicitar un cupón en el enlace: https://ibm.biz/cloudcoupon . La confirmación del cupón se realiza durante la jornada laboral.
- Puede crear un clúster gratuito (un trabajador 2 vCPUs 4GB RAM) desde el catálogo de servicios: https://cloud.ibm.com/kubernetes/catalog/cluster/create
- La creación de un clúster tardará entre 5 y 7 minutos, después de lo cual el clúster IKS estará disponible para usted.
Conclusión
Espero que después de leer este artículo, el lector tenga menos preguntas sobre cómo los kubernetes administrados y el trabajo de turno abierto administrado. Este artículo también se puede usar como una instrucción de acción para implementar sus propios kubernetes. Todas las prácticas utilizadas por IBM son aplicables a las nubes privadas y, con cierto esfuerzo, se implementan en cualquier centro de datos.
Recursos
Holgura IKS
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