istioctl es la forma más rápida de poner Istio en marcha en un clúster, lo que lo convierte en el punto de partida adecuado para aprender la malla aunque Helm (que se cubre en la siguiente guía) encaje mejor en una instalación de producción que vayas a gestionar a largo plazo. Esta guía instala Istio, confirma que está sano e inyecta un sidecar en una carga de trabajo real.

Antes de instalar: recursos del clúster

El plano de control de Istio y los gateways de ingress/egress necesitan CPU y memoria reales, más de lo que suele asignar un clúster local por defecto. En minikube en concreto, inicia el clúster con margen:

minikube start --cpus=4 --memory=8192

Los recursos insuficientes son una fuente común de Pods de Istio atascados en Pending o CrashLoopBackOff en una primera instalación, algo que conviene descartar antes de solucionar cualquier otra cosa.

Instala istioctl

Descarga la versión para tu plataforma desde la página de releases de Istio, o usa el script de instalación:

curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
istioctl version --remote=false

La línea export PATH solo se aplica a tu sesión de shell actual; añádela al perfil de tu shell (~/.bashrc, ~/.zshrc) si quieres que istioctl esté disponible en cada terminal nueva sin repetir este paso.

Instala Istio en el clúster

istioctl install --set profile=demo -y

-y omite la confirmación interactiva. El perfil demo instala el plano de control más los gateways de ingress y egress, con ajustes de recursos lo bastante ligeros para un clúster local; las instalaciones de producción suelen partir del perfil default, más delgado, que se cubre en la guía de Helm. Lista los perfiles disponibles si quieres ver qué incluye cada uno antes de elegir:

istioctl profile list

Confirma la instalación:

kubectl get pods -n istio-system

Deberías ver istiod y, con el perfil demo, istio-ingressgateway e istio-egressgateway, todos en Running.

Confirma que instalar Istio todavía no cambió nada

Vale la pena comprobarlo explícitamente, porque sorprende la primera vez: instalar Istio no tiene ningún efecto sobre las cargas de trabajo existentes. No aparecen sidecars, no cambia nada sobre cómo se ejecutan tus aplicaciones, hasta que habilitas explícitamente la inyección. Istio instalado en el clúster sin usarse te cuesta los recursos que consumen su propio plano de control y sus gateways, nada más.

Habilita la inyección de sidecars en un namespace

kubectl label namespace default istio-injection=enabled
kubectl get namespace default --show-labels

Esto solo afecta a los Pods creados después de aplicar la etiqueta. Para los Pods que ya existían en ese namespace, recréalos:

kubectl delete pods --all -n default
kubectl rollout restart deployment -n default

(O vuelve a aplicar los manifiestos que los crearon originalmente; un kubectl delete simple seguido de un kubectl apply de los mismos archivos sin modificar funciona igual; nada en los manifiestos en sí necesita cambiar para que se aplique la inyección.)

Confirma que un sidecar realmente aterrizó

kubectl get pods -n default

Un Pod con su sidecar presente muestra 2/2 bajo READY en lugar de 1/1. Confirma qué es realmente ese segundo contenedor:

kubectl describe pod <pod-name> -n default

Deberías ver un init container istio-init (que configura la interceptación del tráfico) y un contenedor istio-proxy junto al de tu propia aplicación, listados bajo Containers en la salida.

Inyecta una sola carga de trabajo manualmente, sin etiquetar un namespace

A veces incluir en la malla un namespace entero no es lo que quieres, solo una carga de trabajo concreta. istioctl kube-inject añade el sidecar a un manifiesto antes de aplicarlo, en lugar de depender de la inyección automática a nivel de namespace:

istioctl kube-inject -f my-deployment.yaml | kubectl apply -f -

Es el equivalente manual de lo que desencadena automáticamente la etiqueta del namespace: una especificación de sidecar, generada por istioctl y fusionada en tu manifiesto, aplicada en un solo paso. Útil para un namespace con cargas de trabajo mixtas, unas dentro de la malla y otras no, donde etiquetar todo el namespace metería en la malla más de lo que pretendes.

Desinstalar

istioctl uninstall --purge -y
kubectl delete namespace istio-system

--purge elimina todo lo que añadió la instalación, incluidos los recursos de perfiles distintos del que está activo actualmente, lo que importa si has cambiado de perfil durante las pruebas y quieres una eliminación limpia en lugar de restos de una instalación anterior.