플랫폼별 사전 요구사항

플랫폼별 사전 요구사항 (Platform-Specific Prerequisites)

이 문서는 앰비언트 모드에서 Istio를 설치하기 위한 모든 플랫폼별 또는 환경별 사전 요구사항을 다뤄요.

출처: Istio 문서

본문

플랫폼 (Platform)

일부 쿠버네티스 환경은 이를 지원하기 위해 다양한 Istio 구성 옵션을 설정해야 해요.

Google Kubernetes Engine (GKE)

플랫폼 프로파일 (Platform profile)

GKE를 사용할 때는 설치 명령에 올바른 platform 값을 추가해야 해요. GKE는 CNI 바이너리에 비표준 위치를 사용하므로 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

네임스페이스 제한 (Namespace restrictions)

GKE에서 system-node-critical priorityClassName을 가진 어떤 파드도 ResourceQuota가 정의된 네임스페이스에만 설치할 수 있어요. Istio CNI 노드 에이전트와 ztunnel은 모두 node-critical 클래스를 요구해요.

GKE에서는 기본적으로 kube-system만 node-critical 클래스에 대한 ResourceQuota가 정의되어 있어요. ambient 프로파일로 Istio를 설치하면 istio-system 네임스페이스에 ResourceQuota가 생성돼요.

다른 네임스페이스에 Istio를 설치하려면 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 활성화
그리고 SecurityGroupPolicy를 통한 EKS pod-attached SecurityGroup 사용

POD_SECURITY_GROUP_ENFORCING_MODE를 명시적으로 standard로 설정해야 합니다. 그렇지 않으면 파드 헬스 프로브가 실패해요. Istio가 kubelet 헬스 프로브를 식별하기 위해 link-local SNAT 주소를 사용하는데, VPC CNI가 Pod Security Group strict 모드에서 link-local 패킷을 현재 잘못 라우팅하기 때문이에요. SecurityGroup에 link-local 주소에 대한 CIDR 제외를 명시적으로 추가해도 동작하지 않아요. VPC CNI의 Pod Security Group 모드가 트래픽을 링크 간에 조용히 라우팅하고, SecurityGroup 정책 적용을 위해 trunking된 pod ENI를 통해 루프시키는 방식으로 동작하기 때문이에요. link-local 트래픽은 링크 간에 라우팅될 수 없으므로, Pod Security Group 기능은 설계상 제약으로 이에 대한 정책을 적용할 수 없고, strict 모드에서 패킷을 버려요.

이 제한에 대한 VPC CNI 컴포넌트의 열린 이슈가 있어요. VPC CNI 팀의 현재 권장사항은, Pod Security Group을 사용한다면 strict 모드를 비활성화해서 우회하거나, 파드에 kubelet 기반 프로브 대신 exec 기반 쿠버네티스 프로브를 사용하는 거예요.

pod ENI trunking이 활성화되어 있는지 확인하려면 다음 명령을 실행하세요:

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

클러스터에 pod-attached security group이 있는지 확인하려면 다음 명령을 실행하세요:

$ 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 오버라이드가 필요해요.

Traefik이 Istio의 인그레스 게이트웨이와 충돌하지 않도록 비활성화한 클러스터를 생성하세요:

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

Istio 차트를 설치할 때 global.platform=k3d를 설정하세요. 예:

$ 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

K3s와 함께 번들된 CNI 중 하나를 사용할 때는 설치 명령에 올바른 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

$ istioctl install --set profile=ambient --set values.global.platform=k3s

다만 이러한 위치는 K3s에서 K3s 문서에 따라 오버라이드될 수 있어요. 커스텀, 비번들 CNI로 K3s를 사용한다면 해당 CNI에 대한 올바른 경로를 수동으로 지정해야 해요. 예: /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/

$ 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

MicroK8s에 Istio를 설치한다면 설치 명령에 올바른 platform 값을 추가해야 해요. MicroK8s는 CNI 구성과 바이너리에 비표준 위치를 사용하기 때문이에요. 예:

$ 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

Docker 드라이버와 함께 minikube를 사용한다면, 설치 명령에 올바른 platform 값을 추가해야 해요. Docker와 함께하는 minikube는 컨테이너에 비표준 바인드 마운트 경로를 사용하기 때문이에요. 예:

$ 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는 ztunnel과 istio-cni 컴포넌트가 kube-system 네임스페이스에 설치되어야 하고, 모든 차트에 대해 global.platform=openshift를 설정해야 해요.

OpenShift에 Ambient 데이터플레인 모드를 배포할 때는 OVN-Kubernetes local 게이트웨이 모드를 활성화하기 위해 gatewayConfig 스펙에서 routingViaHost: true를 설정하세요. 이 1회성 구성은 파드 매니페스트에 liveness 또는 readiness 프로브가 포함된 경우 필요해요. 프로브 트래픽이 호스트를 통해 라우팅되고 호스트의 라우팅 테이블에 적용되도록 보장해서, 프로브가 올바르게 동작하는 데 필요한 조건이기 때문이에요. 게이트웨이 모드를 런타임에 구성하려면 여기에 설명된 단계를 따르세요.

설치하는 모든 차트에 --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/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

CNI 플러그인 (CNI plugins)

다음 구성은 특정 CNI 플러그인을 사용할 때 모든 플랫폼에 적용돼요:

Cilium

Cilium은 현재 기본적으로 다른 CNI 플러그인과 그 구성을 적극적으로 삭제하므로, 체이닝을 제대로 지원하려면 cni.exclusive = false로 구성해야 해요. 자세한 내용은 Cilium 문서를 참조하세요.
Cilium의 BPF masquerading은 현재 기본적으로 비활성화되어 있으며, Istio가 Kubernetes 헬스 체크에 link-local IP를 사용하는 것에 문제가 있어요. bpf.masquerade=true로 BPF masquerading을 활성화하는 것은 현재 지원되지 않으며, Istio 앰비언트에서 파드 헬스 체크가 동작하지 않게 돼요. Cilium의 기본 iptables masquerading 구현은 계속 올바르게 동작해야 해요.
Cilium이 노드 신원을 관리하고 노드 수준 헬스 프로브를 파드에 내부적으로 allow-list 하기 때문에, 앰비언트 모드의 Istio 아래에 있는 Cilium CNI 설치에 default-DENY NetworkPolicy를 적용하면 kubelet 헬스 프로브(Cilium이 기본적으로 모든 정책 적용에서 조용히 면제하는)가 차단될 거예요. Istio가 kubelet 헬스 프로브에 link-local SNAT 주소를 사용하는데, Cilium이 이를 인지하지 못하고, Cilium에는 link-local 주소를 정책 적용에서 면제하는 옵션이 없기 때문이에요.

이는 다음 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"

이 정책 오버라이드는 클러스터에 이미 다른 default-deny NetworkPolicy나 CiliumNetworkPolicy가 적용되어 있지 않으면 필요하지 않아요.

자세한 내용은 이슈 #49277과 CiliumClusterWideNetworkPolicy를 참조하세요.

Cilium이 kube-proxy를 대체하는 데 사용될 때는, Cilium 문서에 설명된 대로 앰비언트 모드의 Istio와 제대로 작동하도록 요구되는 추가 구성 옵션에 유의하세요.

플랫폼별 사전 요구사항