Kubernetes se ha convertido, sin duda, en la plataforma dominante para la implementación de contenedores. Proporciona la capacidad de administrar casi todo utilizando sus API y controladores de usuario que extienden su API a través de los recursos del usuario.
Sin embargo, el usuario aún tiene que tomar decisiones detalladas sobre cómo implementar, configurar, administrar y escalar aplicaciones. A discreción del usuario, quedan preguntas sobre el escalado de la aplicación, la protección y el paso del tráfico. Esto distingue a Kubernetes de las “plataformas como servicio” (PaaS) convencionales, como Cloud Foundry y Heroku.
Las plataformas tienen una interfaz de usuario simplificada, centrada en los desarrolladores de aplicaciones que suelen participar en la personalización de aplicaciones individuales. El sistema PaaS subyacente administra el enrutamiento, la implementación y las métricas transparentes para el usuario.
PaaS maneja el flujo de trabajo de entrega en origen al crear una imagen de contenedor personalizada, desplegarla, configurar una nueva ruta y un subdominio DNS para el tráfico entrante. Todo esto se inicia mediante el comando git push .
Kubernetes (intencionalmente) proporciona solo los bloques de construcción básicos para tales plataformas, dando a la comunidad la oportunidad de hacer este trabajo por su cuenta. Como dijo Kelsey Hightower :
Kubernetes es una plataforma para construir plataformas. La mejor posición para comenzar, pero no para terminar.
Como resultado, vemos un montón de ensamblajes de Kubernetes, así como empresas de hosting que están tratando de crear PaaS para Kubernetes, por ejemplo, OpenShift y Rancher. En el contexto del creciente mercado de Kube-PaaS, Knative, creado en julio de 2018 por Google y Pivotal, está entrando en el ring.
Knative fue una colaboración entre Google y Pivotal, con poca colaboración de otras compañías como IBM, RedHat y Solo.im. Ofrece material PaaS similar para Kubernetes con soporte de aplicaciones informáticas sin servidor de primera clase. A diferencia de los ensamblajes de Kubernetes, Knative se instala como un complemento para cualquier clúster de Kubernetes compatible y se configura a través de los recursos del usuario.
¿Qué es el Knative?
Knative se describe como "Una plataforma basada en Kubernetes para entregar y administrar cargas de trabajo con la informática moderna sin servidor". Al declararse a sí mismo como tal plataforma, Knative escala automáticamente los contenedores en proporción a las solicitudes HTTP simultáneas. Los servicios no utilizados finalmente se escalan a cero, lo que proporciona un escalado bajo demanda al estilo de la informática sin servidor.
Knative consta de un conjunto de controladores instalados en cualquier clúster de Kubernetes y ofrece las siguientes características:
- ensamblaje de aplicaciones en contenedores desde el código fuente (proporcionado por el componente Build ),
- proporcionar acceso al tráfico entrante a las aplicaciones (proporcionado por el componente Servir ),
- entrega y escalado automático de aplicaciones bajo demanda (también proporcionado por el componente Serving ),
- determinación de las fuentes de eventos que conducen al lanzamiento de aplicaciones (proporcionadas por el componente Eventing ).
Un componente clave es Serving, que proporciona entrega, autoescalado y control de tráfico para aplicaciones administradas. Después de instalar Knative, todavía tiene acceso completo a la API de Kubernetes, que permite a los usuarios administrar aplicaciones de la manera habitual , y también sirve para depurar los servicios de Knative al trabajar con las mismas primitivas de API que usan estos servicios (módulos, servicios, etc.).
El servicio también automatiza el enrutamiento de tráfico azul-verde, proporcionando separación de tráfico entre las versiones nuevas y antiguas de la aplicación cuando el usuario entrega una versión actualizada de la aplicación.
Knative en sí depende de la instalación de un controlador de ingreso compatible. En el momento de escribir este artículo, se admiten Gloo API Gateway e Istio Service Mesh . Él configurará el ingreso disponible para enrutar el tráfico a las aplicaciones controladas por Knative.
Istio Service Mesh puede convertirse en una gran adicción para los usuarios de Knative que quieran probarlo sin instalar el panel de control de Istio, porque Knative solo depende de la puerta de enlace.
Por esta razón, la mayoría de los usuarios prefieren Gloo como puerta de entrada a Knative, que proporciona un conjunto similar de características con Istio (si hablamos sobre el propósito de usar solo Knative), así como usar significativamente menos recursos y proporcionar costos operativos más bajos.
Vamos a ver Knative en acción en el stand. Usaré un clúster recién instalado que se ejecuta en GKE:
kubectl get namespace NAME STATUS AGE default Active 21h kube-public Active 21h kube-system Active 21h
Procedemos a instalar Knative y Gloo. Esto se puede hacer en cualquier orden:
# Knative-Serving kubectl apply -f \ https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml namespace/knative-serving created # ... # Gloo kubectl apply -f \ https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml namespace/gloo-system created # ...
Verifique que todos los Pods estén en el estado "En ejecución":
kubectl get pod -n knative-serving NAME READY STATUS RESTARTS AGE activator-5dd55958cc-fkp7r 1/1 Running 0 7m32s autoscaler-fd66459b7-7d5s2 1/1 Running 0 7m31s autoscaler-hpa-85b5667df4-mdjch 1/1 Running 0 7m32s controller-85c8bb7ffd-nj9cs 1/1 Running 0 7m29s webhook-5bd79b5c8b-7czrm 1/1 Running 0 7m29s kubectl get pod -n gloo-system NAME READY STATUS RESTARTS AGE discovery-69548c8475-fvh7q 1/1 Running 0 44s gloo-5b6954d7c7-7rfk9 1/1 Running 0 45s ingress-6c46cdf6f6-jwj7m 1/1 Running 0 44s knative-external-proxy-7dd7665869-x9xkg 1/1 Running 0 44s knative-internal-proxy-7775476875-9xvdg 1/1 Running 0 44s
Gloo está listo para el enrutamiento, creemos un servicio Knative escalable automáticamente (llamémoslo kservice) y dirijamos el tráfico hacia él.
Los servicios de Knative proporcionan una manera más fácil de entregar aplicaciones a Kubernetes, en comparación con el modelo de implementación + servicio + ingreso regular. Trabajaremos con tal ejemplo:
apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata: name: helloworld-go namespace: default spec: template: spec: containers: - image: gcr.io/knative-samples/helloworld-go env: - name: TARGET Value: Knative user
Copié esto en un archivo, luego lo apliqué a mi clúster de Kubernetes de esta manera:
kubectl apply -f ksvc.yaml -n default
Podemos ver los recursos creados por Knative en el clúster después de la entrega de nuestro servicio de 'helloworld-go':
kubectl get pod -n default NAME READY STATUS RESTARTS AGE helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68s
El pod con nuestra imagen 'helloworld-go' comienza cuando implementa kservice. Si no hay tráfico, el número de pods se reducirá a cero. Y viceversa, si el número de solicitudes simultáneas excede algún valor de umbral personalizado, el número de pods aumentará.
kubectl get ingresses.networking.internal.knative.dev -n default NAME READY REASON helloworld-go True
Knative configura su ingreso utilizando un recurso especial de 'ingreso' en la API interna de Knative. Gloo toma esta API como su configuración para exponer las propiedades inherentes a PaaS, incluido el modelo de implementación azul-verde, TLS automático, tiempos de espera y otras características avanzadas de enrutamiento.
Después de un tiempo, vemos que nuestras cápsulas han desaparecido (ya que no había tráfico entrante):
kubectl get pod -n default No resources found. kubectl get deployment -n default NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE helloworld-go-fjp75-deployment 0 0 0 0 9m46s
Finalmente, intentaremos llegar a ellos. Obtener URL para Knative Proxy es fácil y fácil con glooctl :
glooctl proxy url --name knative-external-proxy http://35.190.151.188:80
Sin glooctl instalado, puede espiar la dirección y el puerto en el servicio de kube:
kubectl get svc -n gloo-system knative-external-proxy NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE knative-external-proxy LoadBalancer 10.16.11.157 35.190.151.188 80:32168/TCP,443:30729/TCP 77m
Ejecute un poco de datos con cURL:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188 Hello Knative user!
Knative proporciona casi PaaS para desarrolladores además de Kubernetes basado en cajas, utilizando el portal API de alto rendimiento y todas las funciones de Gloo. Esta nota solo tocó ligeramente la gran cantidad de características Knative disponibles para personalización, así como características adicionales. De manera similar con Gloo!
A pesar de que Knative todavía es un proyecto joven, su equipo lanza nuevas versiones cada seis semanas, la implementación de funciones avanzadas ha comenzado, por ejemplo, el despliegue automático de TLS, el escalado automático del panel de control. Existe una alta probabilidad de que, como resultado de la cooperación entre numerosas compañías en la nube, así como la base de la nueva oferta de Cloud Run de Google, Knative se convierta en la principal opción para organizar la computación sin servidor y PaaS en Kubernetes. Sigue las noticias!
De SouthBridge
La opinión de los lectores es importante para nosotros, por lo que le pedimos que participe en una pequeña encuesta relacionada con futuros artículos sobre Knative, Kubernetes, informática sin servidor: