Lo que estoy tratando de hacer
Cree un entorno de Kubernetes con un único servicio de puerta de enlace API asignado a una dirección DNS.
Que he hecho:
1) Fui al servicio AWS Route53 y creé un subdominio.
2) Ese subdominio parece tener una IP estática. Obtuve esta IP haciendo ping al nombre de dominio.
3) He configurado unClúster de Kubernetes en AWS con kops.
4) Tengo un servicio de puerta de enlace cuyos puntos finales acceden a microservicios dentro de la infraestructura k8s.
Este servicio es de tipo LoadBalancer, donde loadBalancerIPes igual a la IP estática de arriba.
El problema:
Con la configuración anterior, el servicio no puede crear con Failed to ensure load balancer for service default/gateway-service: LoadBalancerIP cannot be specified for AWS ELB.
Entonces empiezo a leer lo que parecen recursos bastante buenos sobreEntrada K8(También) y unServicio de proxy inverso de Nginx. (Y este al final) (También este).
Mi errorTambién se ha preguntado antes., y nuevamente la respuesta parece poner otra capa entre mi puerta de enlace API y el mundo exterior.
Luego, después de leer mucho sobre los controladores Nginx Ingress, estoy realmente confundido.
Mis preguntas
a) ¿Existe una razón más importante para tener otra capa entre la puerta de enlace y el mundo exterior además de la compatibilidad?
b) ¿Lo que intenté funcionaría en Google Cloud Platform? (¿Es este un problema específico de la implementación de AWS?)
c) Controlador de ingreso Nginx... ¿Cuál es la diferencia entre un proxy inverso de Nginx y el servicio Kubernetes Ingress? Porque para mí las palabras parecen usarse indistintamente aquí.
d) Parece haber muchas maneras de hacer esto, ¿cuál es el mejor (y más fácil) método actual?
EDITAR:
Implementé la opción 1 de la respuesta de Jonah. Aquí están las configuraciones en caso de que alguien quiera copiar y pegar algo.
servicio-puerta de enlace.yaml:
apiVersion: v1
kind: Service
metadata:
name: gateway-service
spec:
ports:
- name: "gateway"
port: 80
targetPort: 5000
selector:
app: "gateway"
type: LoadBalancer
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: "gateway"
spec:
replicas: 1
template:
metadata:
labels:
app: "gateway"
spec:
containers:
- image: <account_nr>.dkr.ecr.us-east-1.amazonaws.com/gateway
imagePullPolicy: Always
name: "gateway"
ports:
- containerPort: 5000
protocol: "TCP"
Luego, cree el subdominio en AWS Route53:
1) Crear dominio
2) New Record Set
3) Tipo A(IPv 4)
4) Alias yes
5) Seleccione el destino de Alias que coincida con el punto final externo del Servicio. ( kubectl describe services gateway-service | grep LoadBalancer)
Respuesta1
Hay cinco piezas distintas de automatización de infraestructura potencialmente en juego:
- asignación de ip a nodo
- mapeo de nombre dns a ip
- equilibrio de carga para mapeo de miembros
- IP del servicio de Kubernetes al mapeo de miembros del pod y, a veces, al balanceador de carga
- ingreso de kubernetes
Algunos de ellos pueden conducir a algunos de los demás. No necesariamente todos juegan bien juntos y pueden competir entre sí.
Realmente no he mirado el tiempo de ejecución de Kubernetes de Amazon, pero fuera de eso, para hacer lo simple que quieres hacer, conozco al menos 3 opciones:
- A partir de Kubernetes, cree un tipo de servicio = LoadBalancer para que cree un ELB. Esto le dará un nombre de dominio único al que podrá crear un registro CNAME en route53 para asignar su subdominio. La membresía de ELB se actualizará mediante una automatización similar a la que mantiene los servicios actualizados con pod ips. Existen algunas limitaciones en torno al equilibrio de solicitudes de capa 4 y capa 7.
- comience desde un ELB, agregue nodos k8s EC2 como miembros del ELB y ejecute el ingreso como un conjunto de demonios. Hay muchas variantes sobre esto, pero esto significa que la responsabilidad de garantizar que la membresía en ELB sea correcta está ligada a la gestión de k8 en EC2, ya sea automatizada o manual. Pero esto ofrece otros puntos de control sobre el enrutamiento del tráfico de capa 7.
- A partir de Kubernetes, utilice una herramienta llamada route53-mapper para controlar la configuración de Route53 a partir de anotaciones en los recursos del servicio.
https://github.com/kubernetes/kops/tree/master/addons/route53-mapper
Esta es una versión más simple de la primera, que incluye TLS, pero parece un poco loco usarla para TLS porque parece requerir mantener los certificados en las anotaciones de servicio, en lugar de donde pertenecen, en secretos.
Respuestas:
¿Existe una razón más importante para tener otra capa entre la puerta de enlace y el mundo exterior además de la compatibilidad?
No hay ningún requisito, este enfoque resuelve que tanto ELB como los k8 posean automatización. En general, no se quieren propietarios de automatización que compitan entre sí.
¿Lo que intenté funcionaría en Google Cloud Platform? (¿Es este un problema específico de la implementación de AWS)?
La automatización de gcloud es diferente y a sus balanceadores de carga se les puede dar ips, porque tiene una asignación de ip administrada por separado. Hasta cierto punto, este es un problema específico de AWS.
Controlador de ingreso de Nginx... ¿Cuál es la diferencia entre un proxy inverso de Nginx y el servicio de ingreso de Kubernetes? Porque para mí las palabras parecen usarse indistintamente aquí.
Son intercambiables. Uno es una abstracción, el otro es concreto.
Kubernetes Ingress es la abstracción que se puede implementar de muchas maneras diferentes. La entrada comprende recursos de entrada, un controlador y un proxy que toma la configuración. El controlador observa el clúster en busca de cambios en los recursos de entrada, los traduce a una configuración específica del proxy y luego recarga el proxy.
El controlador de ingreso nginx es una implementación de esta maquinaria que utiliza nginx. Hay muchos otros que utilizan haproxy y otros proxies.
Parece que hay muchas maneras de hacer esto, ¿cuál es el mejor (y más fácil) método actual?
Véase más arriba. Probablemente también haya otras formas.