Recientemente, he creado varios microservicios dentro de un clúster k8s con el controlador de entrada Nginx y funcionan normalmente.
Al tratar con comunicaciones entre microservicios, probé gRPC y funcionó. Luego descubro que cuando el microservicio A -> gRPC -> microservicio B, todas las solicitudes solo ocurrieron en 1 pod del microservicio B (por ejemplo, un total de 10 pods disponibles para el microservicio B). Para equilibrar la carga de las solicitudes a todos los pods del microservicio B, probé linkerd y funcionó. Sin embargo, me di cuenta de que gRPC a veces produce un error interno (p. ej., 1 error de cada 100 solicitudes), lo que me obliga a cambiar a la forma DNS k8s (p. ej., my-svc.my-namespace.svc.cluster-domain.example). Entonces, las solicitudes nunca fallan. Empecé a retrasar gRPC y linkerd.
Más tarde, me interesé por istio. Lo implementé con éxito en el clúster. Sin embargo, observo que siempre crea su propio balanceador de carga, que no coincide tanto con el controlador de ingreso Nginx existente.
Además, prometeo y grafana, así como k9s. Estas herramientas me permiten comprender mejor el uso de CPU y memoria de los pods.
Aquí tengo varias preguntas que deseo entender: -
En realidad, también quiero usar Service Mesh todos los días.
La respuesta sencilla es
Service mesh para un servidor kubernetes no es necesario
Ahora para responder a sus preguntas
Si necesito monitorear los recursos del clúster, tenemos prometheus, grafana y k9s. ¿Están desempeñando la misma función de supervisión que Service Mesh (por ejemplo, linkerd, istio)?
K9s es una herramienta cli que es solo un reemplazo de la herramienta kubectl cli. No es una herramienta de monitoreo. Prometheus y grafana son herramientas de monitoreo que necesitarán utilizar los datos proporcionados por las aplicaciones (pods) y generar datos de series de tiempo que se pueden visualizar como tablas, gráficos, etc. Sin embargo, las aplicaciones deben proporcionar los datos de monitoreo a Prometheus. Las mallas de servicio pueden usar un sidecar y proporcionar algunas métricas predeterminadas útiles para monitorear, como la number of requests handled in a second . Su aplicación no necesita tener ningún conocimiento o implementación de las métricas. Por lo tanto, las mallas de servicios son opcionales y descargan cosas comunes como el monitoreo o la autorización.
si k8s DNS ya puede lograr el equilibrio de carga, ¿todavía necesitamos Service Mesh?
Las mallas de servicio no son necesarias para el equilibrio de carga. Cuando tiene varios servicios ejecutándose en el clúster y desea usar un único punto de entrada para todos sus servicios para simplificar el mantenimiento y ahorrar costos, se usan controladores de ingreso como Nginx, Traefik, HAProxy. Además, las mallas de servicio como Istio vienen con su propio controlador de ingreso.
si usa k8s sin malla de servicio, ¿está retrasado con respecto a la práctica normal?
No, puede haber clústeres que no tengan mallas de servicio hoy y aún usen Kubernetes.
En el futuro, Kubernetes puede traer algunas funcionalidades de mallas de servicio.
La malla de servicio no es una panacea y no encaja en todos los casos de uso. Service Mesh no hará todo por usted, también tiene errores y funciones limitadas.