Передумови, специфічні для певних платформ

 5 хвилин(и)     перевірка сторінки

Цей документ охоплює будь-які специфічні для платформи або середовища вимоги для установки Istio в режимі ambient.

Платформа

Деякі середовища Kubernetes вимагають налаштування різних параметрів конфігурації Istio для їх підтримки.

Google Kubernetes Engine (GKE)

У GKE компоненти Istio з priorityClassName system-node-critical можуть бути встановлені лише в просторах імен, в яких визначено ResourceQuota. Стандартно у GKE лише kube-system має визначений ResourceQuota для класу node-critical. Історичний агент CNI та ztunnel обидва потребують класу node-critical, тому в GKE обидва компоненти повинні бути:

  • Встановлені в kube-system (не в istio-system)
  • Встановлені в інший простір імен (наприклад, istio-system), в якому вручну створено ResourceQuota, наприклад:
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

Amazon Elastic Kubernetes Service (EKS)

Якщо ви використовуєте EKS:

  • з Amazon VPC CNI
  • з увімкненим Pod ENI trunking
  • та використовуєте прикріплені до подів SecurityGroups через SecurityGroupPolicy

POD_SECURITY_GROUP_ENFORCING_MODE має бути явно встановлено в значення standard, інакше проби справності подів (які за стандартно автоматично виключені з політики VPC CNI) будуть провалені. Це повʼязано з тим, що Istio використовує локальну SNAT-адресу для проб справності kubelet, яку Amazon VPC CNI не розпізнає, а VPC CNI не має опції для виключення локальних адрес з політики.

Ви можете перевірити, чи увімкнено pod ENI trunking, виконавши наступну команду:

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

Ви можете перевірити, чи є у вашому кластері будь-які прикріплені до подів групи безпеки, виконавши таку команду:

$ kubectl get securitygrouppolicies.vpcresources.k8s.aws

Ви можете встановити POD_SECURITY_GROUP_ENFORCING_MODE=standard, виконавши наступну команду, після чого перезапустіть відповідні поди:

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

k3d

Коли ви використовуєте k3d зі стандартним Flannel CNI, вам потрібно додати коректне значення platform до вашої команди встановлення, оскільки k3d використовує нестандартні розташування для конфігурацій CNI та двійкових файлів, що потребують певних перевизначень в Helm.

  1. Створіть кластер з вимкненим Traefik, щоб уникнути конфлікту з ingress gateways Istio:

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

  2. Встановіть global.platform=k3d під час встановлення чартів Istio. Наприклад:

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

K3s

Коли ви використовуєте K3s та один з його вбудованих CNIs, ви повинні додати правильне значення platform до ваших команд установки, оскільки K3s використовує нестандартні розташування для конфігурацій CNI та бінарних файлів, що вимагає деяких перевизначень в Helm. Для стандартних шляхів K3s Istio надає вбудовані перевизначення на основі значення global.platform.

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

Однак ці розташування можуть бути перевизначені в K3s, згідно з документацією K3s. Якщо ви використовуєте K3s з власним, не вбудованим CNI, ви повинні вручну вказати правильні шляхи для цих CNIs, наприклад, /etc/cni/net.d — див. документацію K3s для деталей. Наприклад:

$ 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

Якщо ви встановлюєте Istio на MicroK8s, вам потрібно додати коректне значення platform до вашої команди встановлення, оскільки MicroK8s використовує нестандартні розташування для конфігурації CNI та двійкових файлів. Наприклад:

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

minikube

Якщо ви використовуєте minikube з Docker-драйвером, вам потрібно додати коректне значення platform до вашої команди встановлення, оскільки minikube з Docker використовує нестандартні привʼязки монтування шляхів для контейнерів. Наприклад:

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

Red Hat OpenShift

OpenShift вимагає, щоб компоненти ztunnel та istio-cni були встановлені в просторі імен kube-system, і щоб для всіх чартів було встановлено global.platform=openshift.

Ви повинні встановити --set global.platform=openshift для кожного чарту, які ви встановлюєте, ось приклад з чартом istiod:

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

На додачу, ви маєте встановити istio-cni та ztunnel в простір імен kube-system, наприклад:

$ helm install istio-cni istio/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

Втулки CNI

Наведені нижче конфігурації застосовуються до всіх платформ, якщо використовуються певні втулки CNI:

Cilium

  1. Cilium наразі стандартно проактивно видаляє інші втулки CNI та їх конфігурацію, і його потрібно налаштувати з cni.exclusive = false, щоб правильно підтримувати ланцюжки. Див. документацію Cilium для більш детальної інформації.

  2. BPF маскування в Cilium наразі стандартно вимкнено і має проблеми з використанням локальних IP-адрес Istio для перевірки справності Kubernetes. Увімкнення BPF маскування через bpf.masquerade=true наразі не підтримується і призводить до того, що в Istio ambient зʼявляються нефункціональні перевірки стану справності podʼів. Стандартна реалізація маскування iptables Cilium повинна продовжувати функціонувати правильно.

  3. Завдяки тому, як Cilium керує ідентифікацією вузлів та внутрішніми списками дозволів на рівні вузлів, проби справності можуть бути передані до подів, застосування будь-якої політики default-DENY NetworkPolicy в установці Cilium CNI, що лежить в основі Istio, у зовнішньому режимі призведе до блокування проб справності kubelet (які стандартно мовчки вилучаються з усіх політик, що застосовуються Cilium). Це повʼязано з тим, що Istio використовує локальну SNAT-адресу для перевірок справності kubelet, про яку Cilium не знає, а Cilium не має можливості вилучити локальні адреси з-під дії політик.

    Це можна вирішити, застосувавши наступну CiliumClusterWideNetworkPolicy:

    apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: "allow-ambient-hostprobes"
spec:
  description: "Allows SNAT-ed kubelet health check probes into ambient pods"
  enableDefaultDeny:
    egress: false
    ingress: false
  endpointSelector: {}
  ingress:
  - fromCIDR:
    - "169.254.7.127/32"

    Див. тікет #49277 та CiliumClusterWideNetworkPolicy для більш детальної інформації.

Чи була ця інформація корисною?
Чи є у вас пропозиції щодо покращення?

Дякуємо за ваш відгук!