Prerrequisitos específicos de la plataforma

 lectura de 7 minutos     prueba de página

Este documento cubre cualquier prerrequisito específico de la plataforma o del entorno para instalar Istio en modo ambient.

Plataforma

Ciertos entornos de Kubernetes requieren que establezcas varias opciones de configuración de Istio para admitirlos.

Google Kubernetes Engine (GKE)

Restricciones de namespaces

En GKE, cualquier pod con la priorityClassName system-node-critical solo se puede instalar en namespaces que tengan definida una ResourceQuota. De forma predeterminada en GKE, solo kube-system tiene una ResourceQuota definida para la clase node-critical. El agente de nodo CNI de Istio y ztunnel requieren la clase node-critical, por lo que en GKE, ambos componentes deben:

  • Instalarse en kube-system (no en istio-system)
  • Instalarse en otro namespaces (como istio-system) en el que se haya creado manualmente una ResourceQuota, por ejemplo:
apiVersion: v1
kind: ResourceQuota
metadata:
  name: gcp-critical-pods
  namespace: istio-system
spec:
  hard:
    pods: 1000
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
      - system-node-critical

Perfil de plataforma

Cuando uses GKE, debes agregar el valor de platform correcto a tus comandos de instalación, ya que GKE usa ubicaciones no estándar para los binarios de CNI, lo que requiere anulaciones de Helm.

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=gke --wait

Amazon Elastic Kubernetes Service (EKS)

Si estás usando EKS:

  • con el CNI de VPC de Amazon
  • con el enlace de ENI de pod habilitado
  • y estás usando SecurityGroups adjuntos a pods de EKS a través de SecurityGroupPolicy

POD_SECURITY_GROUP_ENFORCING_MODE debe establecerse explícitamente en standard, o las sondas de salud del pod fallarán. Esto se debe a que Istio usa una dirección SNAT de enlace local para identificar las sondas de salud de kubelet, y el CNI de VPC actualmente enruta incorrectamente los paquetes de enlace local en el modo strict de Pod Security Group. Agregar explícitamente una exclusión de CIDR para la dirección de enlace local a tu SecurityGroup no funcionará, porque el modo de Pod Security Group del CNI de VPC funciona enrutando silenciosamente el tráfico a través de enlaces, haciéndolos pasar por el ENI de pod troncal para la aplicación de la política de SecurityGroup. Dado que el tráfico de enlace local no se puede enrutar a través de enlaces, la característica de Pod Security Group no puede aplicar políticas contra ellos como una restricción de diseño y descarta los paquetes en modo strict.

Hay un problema abierto en el componente CNI de VPC para esta limitación. La recomendación actual del equipo de CNI de VPC es deshabilitar el modo strict para solucionarlo, si estás usando Pod Security Groups, o usar sondas de Kubernetes basadas en exec para tus pods en lugar de las basadas en kubelet.

Puedes verificar si tienes habilitado el enlace de ENI de pod ejecutando el siguiente comando:

$ kubectl set env daemonset aws-node -n kube-system --list | grep ENABLE_POD_ENI

Puedes verificar si tienes algún grupo de seguridad adjunto a un pod en tu cluster ejecutando el siguiente comando:

$ kubectl get securitygrouppolicies.vpcresources.k8s.aws

Puedes establecer POD_SECURITY_GROUP_ENFORCING_MODE=standard ejecutando el siguiente comando y reciclando los pods afectados:

$ kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard

k3d

Cuando uses k3d con el CNI de Flannel predeterminado, debes agregar el valor de platform correcto a tus comandos de instalación, ya que k3d usa ubicaciones no estándar para la configuración y los binarios de CNI, lo que requiere algunas anulaciones de Helm.

  1. Crea un cluster con Traefik deshabilitado para que no entre en conflicto con las gateways de entrada de Istio:

    $ k3d cluster create --api-port 6550 -p '9080:80@loadbalancer' -p '9443:443@loadbalancer' --agents 2 --k3s-arg '--disable=traefik@server:*'

  2. Establece global.platform=k3d al instalar los charts de Istio. Por ejemplo:

    $ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=k3d --wait

K3s

Cuando uses K3s y uno de sus CNI incluidos, debes agregar el valor de platform correcto a tus comandos de instalación, ya que K3s usa ubicaciones no estándar para la configuración y los binarios de CNI, lo que requiere algunas anulaciones de Helm. Para las rutas predeterminadas de K3s, Istio proporciona anulaciones integradas basadas en el valor global.platform.

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=k3s --wait

Sin embargo, estas ubicaciones se pueden anular en K3s, según la documentación de K3s. Si estás usando K3s con un CNI personalizado no incluido, debes especificar manualmente las rutas correctas para esos CNI, por ejemplo, /etc/cni/net.d; consulta la documentación de K3s para obtener más detalles. Por ejemplo:

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --wait --set cniConfDir=/var/lib/rancher/k3s/agent/etc/cni/net.d --set cniBinDir=/var/lib/rancher/k3s/data/current/bin/

MicroK8s

Si estás instalando Istio en MicroK8s, debes agregar el valor de platform correcto a tus comandos de instalación, ya que MicroK8s usa ubicaciones no estándar para la configuración y los binarios de CNI. Por ejemplo:

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=microk8s --wait

minikube

Si estás usando minikube con el controlador de Docker, debes agregar el valor de platform correcto a tus comandos de instalación, ya que minikube con Docker usa una ruta de montaje de enlace no estándar para los contenedores. Por ejemplo:

$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=minikube --wait"

Red Hat OpenShift

OpenShift requiere que los componentes ztunnel e istio-cni se instalen enel namespace kube-system, y que establezcas global.platform=openshift para todos los charts.

Debes --set global.platform=openshift para cada chart que instales, por ejemplo, con el chart istiod:

$ helm install istiod istio/istiod -n istio-system --set profile=ambient --set global.platform=openshift --wait

Además, debes instalar istio-cni y ztunnel enel namespace kube-system, por ejemplo:

$ helm install istio-cni istio/cni -n kube-system --set profile=ambient --set global.platform=openshift --wait
$ helm install ztunnel istio/ztunnel -n kube-system --set profile=ambient --set global.platform=openshift --wait

Complementos de CNI

Las siguientes configuraciones se aplican a todas las plataformas, cuando se utilizan ciertos complementos de CNI:

Cilium

  1. Cilium actualmente tiene como valor predeterminado eliminar proactivamente otros complementos de CNI y su configuración, y debe configurarse con cni.exclusive = false para admitir correctamente el encadenamiento. Consulta la documentación de Cilium para obtener más detalles.

  2. El enmascaramiento BPF de Cilium está actualmente deshabilitado de forma predeterminada y tiene problemas con el uso de Istio de IP de enlace local para la verificación de estado de Kubernetes. Habilitar el enmascaramiento BPF a través de bpf.masquerade=true no es compatible actualmente y da como resultado verificaciones de estado de pod no funcionales en Istio ambient. La implementación de enmascaramiento de iptables predeterminada de Cilium debería seguir funcionando correctamente.

  3. Debido a cómo Cilium administra la identidad del nodo e internamente permite las sondas de estado a nivel de nodo a los pods, aplicar cualquier NetworkPolicy de DENEGACIÓN predeterminada en una instalación de Cilium CNI subyacente a Istio en modo ambient hará que las sondas de estado de kubelet (que por defecto están exentas silenciosamente de toda aplicación de políticas por parte de Cilium) se bloqueen. Esto se debe a que Istio usa una dirección SNAT de enlace local para las sondas de estado de kubelet, de la que Cilium no tiene conocimiento, y Cilium no tiene una opción para eximir las direcciones de enlace local de la aplicación de políticas.

    Esto se puede resolver aplicando la siguiente CiliumClusterWideNetworkPolicy:

    apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: "allow-ambient-hostprobes"
spec:
  description: "Permite que las sondas de verificación de estado de kubelet con SNAT ingresen a los pods ambient"
  enableDefaultDeny:
    egress: false
    ingress: false
  endpointSelector: {}
  ingress:
  - fromCIDR:
    - "169.254.7.127/32"

    Esta anulación de política no es necesaria a menos que ya tengas otras NetworkPolicies o CiliumNetworkPolicies de denegación predeterminada aplicadas en tu cluster.

    Consulta el problema #49277 y CiliumClusterWideNetworkPolicy para obtener más detalles.

¿Fue útil esta información?
¿Tienes alguna sugerencia para mejorar?

¡Gracias por tus comentarios!