Prerrequisitos específicos de la plataforma
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 enistio-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
$ istioctl install --set profile=ambient --set values.global.platform=gke
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.
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:*'
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
$ istioctl install --set profile=ambient --set values.global.platform=k3d
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
$ istioctl install --set profile=ambient --set values.global.platform=k3s
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/
$ istioctl install --set profile=ambient --set values.cni.cniConfDir=/var/lib/rancher/k3s/agent/etc/cni/net.d --set values.cni.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
$ istioctl install --set profile=ambient --set values.global.platform=microk8s
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"
$ istioctl install --set profile=ambient --set values.global.platform=minikube"
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
$ istioctl install --set profile=openshift-ambient --skip-confirmation
Complementos de CNI
Las siguientes configuraciones se aplican a todas las plataformas, cuando se utilizan ciertos complementos de CNI:
Cilium
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.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.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 dekubelet
(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
oCiliumNetworkPolicies
de denegación predeterminada aplicadas en tu cluster.Consulta el problema #49277 y CiliumClusterWideNetworkPolicy para obtener más detalles.