
Indudablemente, Kubernetes se ha convertido en la plataforma dominante para el despliegue de contenedores. Proporciona la capacidad de manejar casi todo, utilizando sus API y controladores personalizados que amplían su API a través de recursos personalizados.
Sin embargo, el usuario todavía debe tomar decisiones detalladas sobre cómo desplegar, configurar, gestionar y escalar aplicaciones. Cuestiones como la escalabilidad de la aplicación, la seguridad y la gestión del tráfico quedan a criterio del usuario. Esta es la principal diferencia de Kubernetes frente a las plataformas convencionales como servicio (PaaS), como Cloud Foundry y Heroku.
Las plataformas tienen una interfaz de usuario simplificada, orientada a desarrolladores de aplicaciones que a menudo se centran en la configuración de aplicaciones individuales. La gestión de la enrutación, el despliegue y las métricas se maneja de forma transparente para el usuario por el sistema base de PaaS.
El flujo de trabajo "código fuente - entrega" se procesa en PaaS creando una imagen de contenedor personalizada, desplegándola, configurando una nueva ruta y subdominio DNS para el tráfico entrante. Todo esto se activa con un comando. git push.
Kubernetes proporciona (intencionadamente) solo los bloques básicos para tales plataformas, dando a la comunidad la oportunidad de realizar este trabajo por sí misma. Como :
Kubernetes es una plataforma para construir plataformas. Es la mejor posición para empezar, pero no para terminar.
Como resultado, vemos un montón de compilaciones de Kubernetes, así como servicios de hosting que intentan crear PaaS para Kubernetes, como OpenShift y Rancher. En el creciente mercado de Kube-PaaS, aparece Knative, creado en julio de 2018 por Google y Pivotal.
Knative surgió de la colaboración entre Google y Pivotal, con la pequeña participación de otras empresas como IBM, RedHat y Solo.im. Ofrece funcionalidades PaaS similares para Kubernetes con soporte de primera clase para aplicaciones basadas en computación serverless. A diferencia de las compilaciones de Kubernetes, Knative se instala como un complemento en cualquier clúster de Kubernetes compatible, y se configura a través de recursos personalizados.
¿Qué es Knative?
Knative se describe como «Una plataforma basada en Kubernetes para el despliegue y la gestión de cargas de trabajo utilizando cálculos sin servidor modernos». Al declararse como tal, Knative escala automáticamente los contenedores proporcionalmente a las solicitudes HTTP concurrentes. Los servicios que no se utilizan eventualmente se escalan a cero, proporcionando escalado a demanda al estilo de los cálculos sin servidor.
Knative consiste en un conjunto de controladores que se instalan en cualquier clúster de Kubernetes y proporcionan las siguientes capacidades:
- la creación de aplicaciones en contenedores a partir de código fuente (proporcionado por el componente Build),
- la provisión de acceso al tráfico entrante a las aplicaciones (proporcionado por el componente Serving),
- la entrega y el escalado automático de aplicaciones a demanda (también proporcionado por el componente Serving),
- la definición de fuentes de eventos que inician aplicaciones (proporcionado por el componente Eventing).
El componente clave es Serving, que proporciona entrega, escalado automático y gestión del tráfico para aplicaciones administradas. Tras la instalación de Knative, se mantiene el acceso completo a la API de Kubernetes, lo que permite a los usuarios gestionar las aplicaciones de manera convencional, y también sirve para depurar los servicios de Knative, trabajando con los mismos primitivas de la API que utilizan esos servicios (módulos, servicios, etc.).
Con Serving también se automatiza la enrutación de tráfico blue-green, asegurando la separación del tráfico entre nuevas y antiguas versiones de la aplicación al desplegar una versión actualizada por el usuario.
Knative depende de la instalación de un controlador de ingreso compatible. En el momento de escribir este artículo, se soportan y . Este configurará un ingreso disponible para enrutar el tráfico hacia las aplicaciones gestionadas a través de Knative.
Istio Service Mesh puede convertirse en una gran dependencia para los usuarios de Knative que deseen probarlo sin instalar el panel de control de Istio, ya que Knative solo depende del gateway.
Por esta razón, la mayoría de los usuarios prefieren Gloo como puerta de enlace para Knative, ya que ofrece un conjunto similar de características a Istio (si hablamos de su uso solo con Knative), además de utilizar significativamente menos recursos y generar menores costos operativos.
Vamos a probar Knative en acción en el entorno. Usaré un clúster recién instalado, ejecutado en GKE:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hComencemos con la instalación de 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
# ...Verificamos que todos los Pods estén en estado «Running»:
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 44sGloo está listo para el enrutamiento, vamos a crear un servicio Knative que se escale automáticamente (lo llamaremos kservice) y le dirigiremos el tráfico.
Los servicios Knative ofrecen una forma más sencilla de desplegar aplicaciones en Kubernetes en comparación con el modelo convencional de Deployment+Service+Ingress. Trabajaremos con el siguiente 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: Usuario de KnativeLo copié en un archivo, luego lo apliqué a mi clúster de Kubernetes de la siguiente manera:
kubectl apply -f ksvc.yaml -n defaultPodemos ver los recursos creados por Knative en el clúster después de desplegar nuestro ‘helloworld-go’ kservice:
kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68sEl Pod con nuestra imagen ‘helloworld-go’ se inicia al desplegar el kservice. Si no hay tráfico, el número de pods se reducirá a cero. Por el contrario, si el número de solicitudes concurrentes supera cierto umbral configurable, el número de pods aumentará.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative configura su ingress utilizando un recurso especial de ‘ingress’ en la API interna de Knative. Gloo toma esta API como su configuración para proporcionar características propias de PaaS, incluyendo el modelo de despliegue blue-green, la aplicación automática de TLS, los tiempos de espera y otras funciones avanzadas de enrutamiento.
Después de un tiempo, vemos que nuestros pods han desaparecido (ya que no había tráfico entrante):
kubectl get pod -n default
No se encontraron recursos.
kubectl get deployment -n default
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
helloworld-go-fjp75-deployment 0 0 0 0 9m46sFinalmente, intentaremos contactarlos. Obtener la URL para el Proxy de Knative es fácil y sencillo utilizando glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Sin estar configurado glooctl se puede ver la dirección y el puerto en el servicio 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 77mVamos a correr algunos datos con cURL:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
¡Hola usuario de Knative!Knative proporciona casi-PaaS para desarrolladores sobre Kubernetes «listo para usar», utilizando el potente y completo gateway API Gloo. Esta nota apenas tocó la vasta cantidad de características de Knative disponibles para personalización, así como funciones adicionales. ¡Lo mismo sucede con Gloo!
A pesar de que Knative sigue siendo un proyecto joven, su equipo lanza nuevas versiones cada seis semanas, se ha comenzado la implementación de funciones avanzadas, como el despliegue automático de TLS, el escalado automático del panel de control. Hay una alta probabilidad de que, como resultado de la colaboración de numerosas empresas en la nube, y como base de la nueva oferta Cloud Run de Google, Knative pueda convertirse en la opción principal para la organización de computación sin servidor y PaaS en Kubernetes. ¡Estén atentos a las novedades!
De la redacción de SouthBridge
Valoramos la opinión de nuestros lectores, por eso les pedimos participar en una pequeña encuesta relacionada con futuros artículos sobre Knative, Kubernetes, computación sin servidor:
Solo los usuarios registrados pueden participar en la encuesta. , por favor.
¿Deberíamos seguir escribiendo artículos y guías sobre Knative y computación sin servidor?
Sí, por favor.
Gracias, no es necesario.
28 usuarios votaron. 4 usuarios se abstuvieron.
Fuente: habr.com
