AKS(Azure Kubernetes Service)에서 Cilium 기반 Azure CNI 구성

Cilium에서 제공하는 Azure CNI는 Azure CNI의 강력한 컨트롤 플레인과 Cilium의 데이터 평면을 결합하여 고성능 네트워킹 및 보안을 제공합니다.

Linux 커널 및 보다 효율적인 API 개체 구조에 로드된 eBPF 프로그램을 사용하여 Cilium에서 제공하는 Azure CNI는 다음과 같은 이점을 제공합니다.

  • 기존 Azure CNI 및 Azure CNI 오버레이 플러그 인과 동일한 기능

  • 향상된 서비스 라우팅

  • 보다 효율적인 네트워크 정책 적용

  • 클러스터 트래픽의 가시성 향상

  • 더 큰 클러스터(더 많은 노드, Pod 및 서비스)에 대한 지원

Cilium에서 제공하는 Azure CNI로 IPAM(IP 주소 관리)

Cilium에서 제공하는 Azure CNI는 Pod IP를 할당하는 두 가지 방법을 사용하여 배포할 수 있습니다.

  • 오버레이 네트워크에서 IP 주소 할당(Azure CNI 오버레이 모드와 유사)

  • 가상 네트워크에서 IP 주소 할당(동적 Pod IP 할당을 사용하는 기존 Azure CNI와 유사)

어떤 옵션을 선택할지 잘 모르는 경우 "사용할 네트워크 모델 선택"을 참조하세요.

네트워크 정책 적용

Cilium는 네트워크 정책을 적용하여 Pod 간의 트래픽을 허용하거나 거부합니다. Cilium을 사용하면 Azure Network Policy Manager 또는 Calico와 같은 별도의 네트워크 정책 엔진을 설치할 필요가 없습니다.

제한 사항

Cilium에서 제공하는 Azure CNI에는 현재 다음과 같은 제한 사항이 있습니다.

  • Linux에서만 사용할 수 있고 Windows에서는 사용할 수 없습니다.

  • Cilium L7 정책 적용을 사용할 수 없습니다.

  • Hubble을 사용할 수 없습니다.

  • 네트워크 정책은 ipBlock을 사용하여 노드 또는 Pod IP에 대한 액세스를 허용할 수 없습니다. 자세한 내용 및 권장 해결 방법은 질문과 대답을 참조하세요.

  • internalTrafficPolicy=Local을 사용하는 Kubernetes 서비스는 지원되지 않습니다(Cilium 문제 #17796).

  • 여러 Kubernetes 서비스는 다른 프로토콜(예: TCP 또는 UDP)에서 동일한 호스트 포트를 사용할 수 없습니다(Cilium 문제 #14287).

  • Pod가 서비스 클러스터 IP를 통해 자기 자산에 연결될 때 회신 패킷에 네트워크 정책이 적용될 수 있습니다(Cilium 문제 #19406).

필수 조건

  • Azure CLI, 버전 2.48.1 이상 az --version을 실행하여 현재 설치된 버전을 확인합니다. 설치 또는 업그레이드해야 하는 경우 Azure CLI 설치를 참조하세요.

  • ARM 템플릿 또는 REST API를 사용하는 경우 AKS API 버전은 2022-09-02-preview 이상이어야 합니다.

참고 항목

이전 AKS API 버전(2022-09-02preview to 2023-01-02preview)에서는 networkProfile.ebpfDataplane=cilium 필드를 사용했습니다. 2023년 2월 2일 미리 보기 이후 AKS API 버전은 networkProfile.networkDataplane=cilium 필드를 사용하여 Cilium에서 제공하는 Azure CNI를 사용하도록 설정합니다.

Cilium에서 제공하는 Azure CNI를 사용하여 새 AKS 클러스터 만들기

옵션 1: 오버레이 네트워크에서 IP 주소 할당

오버레이 네트워크와 Cilium이 포함된 클러스터를 만들려면 다음 명령을 사용합니다. <clusterName>, <resourceGroupName><location>에 대한 값을 대체합니다.

az aks create -n <clusterName> -g <resourceGroupName> -l <location> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16 \
  --network-dataplane cilium

참고 항목

--network-dataplane cilium 플래그는 이전 버전의 aks-preview CLI 확장에서 사용된 더 이상 사용되지 않는 --enable-ebpf-dataplane 플래그를 바꿉니다.

옵션 2: 가상 네트워크에서 IP 주소 할당

다음 명령을 실행하여 노드용 서브넷과 Pod용 서브넷이 있는 리소스 그룹 및 가상 네트워크를 만듭니다.

# Create the resource group
az group create --name <resourceGroupName> --location <location>
# Create a virtual network with a subnet for nodes and a subnet for pods
az network vnet create -g <resourceGroupName> --location <location> --name <vnetName> --address-prefixes <address prefix, example: 10.0.0.0/8> -o none 
az network vnet subnet create -g <resourceGroupName> --vnet-name <vnetName> --name nodesubnet --address-prefixes <address prefix, example: 10.240.0.0/16> -o none 
az network vnet subnet create -g <resourceGroupName> --vnet-name <vnetName> --name podsubnet --address-prefixes <address prefix, example: 10.241.0.0/16> -o none 

--network-dataplane cilium을 사용하여 클러스터를 만듭니다.

az aks create -n <clusterName> -g <resourceGroupName> -l <location> \
  --max-pods 250 \
  --network-plugin azure \
  --vnet-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/nodesubnet \
  --pod-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/podsubnet \
  --network-dataplane cilium

기존 클러스터를 Cilium 기반 Azure CNI로 업그레이드

참고 항목

클러스터가 다음 기준을 충족하는 경우 기존 클러스터를 Cilium 기반 Azure CNI로 업데이트할 수 있습니다.

참고 항목

다른 네트워크 정책 엔진(Azure NPM 또는 Calico)이 있는 클러스터에서 Cilium을 사용하도록 설정하면 네트워크 정책 엔진이 제거되고 Cilium으로 대체됩니다. 자세한 내용은 Azure 네트워크 정책 관리자 또는 Calico 제거를 참조하세요.

Warning

업그레이드 프로세스는 각 노드 풀을 동시에 이미지로 다시 생성하도록 트리거합니다. 각 노드 풀을 개별적으로 업그레이드하는 것은 지원되지 않습니다. 클러스터 네트워킹 중단은 노드 풀의 각 노드가 다시 이미지화되는 노드 이미지 업그레이드 또는 Kubernetes 버전 업그레이드와 유사합니다.

Cilium은 모든 노드의 이미지가 다시 생성된 후에만 네트워크 정책을 적용하기 시작합니다.

업그레이드를 수행하려면 Azure CLI 버전 2.52.0 이상이 필요합니다. az --version을 실행하여 현재 설치된 버전을 확인합니다. 설치 또는 업그레이드해야 하는 경우 Azure CLI 설치를 참조하세요.

다음 명령을 사용하여 기존 클러스터를 Cilium에서 제공하는 Azure CNI로 업그레이드합니다. <clusterName><resourceGroupName>에 대한 값을 대체합니다.

az aks update -n <clusterName> -g <resourceGroupName> \
  --network-dataplane cilium

자주 묻는 질문

  • Cilium 구성을 사용자 지정할 수 있나요?

    아니요, AKS는 Cilium 구성을 관리하며 수정할 수 없습니다. 더 많은 제어가 필요한 고객은 AKS BYO CNI를 사용하고 Cilium을 수동으로 설치하는 것이 좋습니다.

  • Kubernetes NetworkPolicy 리소스 대신 CiliumNetworkPolicy 사용자 지정 리소스를 사용할 수 있나요?

    CiliumNetworkPolicy 사용자 지정 리소스는 공식적으로 지원되지 않습니다. 고객은 Kubernetes NetworkPolicy 리소스를 사용하여 네트워크 정책을 구성하는 것이 좋습니다.

  • NetworkPolicy에 IP 주소를 허용하는 ipBlock이 있는 경우 트래픽이 차단되는 이유는 무엇인가요?

    Cilium에서 제공하는 Azure CNI의 제한 사항은 NetworkPolicyipBlock이 Pod 또는 노드 IP를 선택할 수 없다는 것입니다.

    예를 들어 이 NetworkPolicy에는 0.0.0.0/0에 대한 모든 송신을 허용하는 ipBlock이 있습니다.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: example-ipblock
    spec:
      podSelector: {}
      policyTypes:
        - Egress
      egress:
        - to:
          - ipBlock:
              cidr: 0.0.0.0/0 # This will still block pod and node IPs.
    

    그러나 이 NetworkPolicy가 적용되면 Cilium은 IP가 ipBlock CIDR 내에 있더라도 Pod 및 노드 IP로의 송신을 차단합니다.

    해결 방법으로 namespaceSelectorpodSelector를 추가하여 Pod를 선택할 수 있습니다. 아래 예제에서는 모든 네임스페이스의 모든 Pod를 선택합니다.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: example-ipblock
    spec:
      podSelector: {}
      policyTypes:
        - Egress
      egress:
        - to:
          - ipBlock:
              cidr: 0.0.0.0/0
          - namespaceSelector: {}
          - podSelector: {}
    

    참고 항목

    현재 노드 IP에 대한 트래픽을 허용하기 위해 ipBlock을 사용하여 NetworkPolicy를 지정할 수 없습니다.

  • AKS는 Cilium daemonset에서 CPU 또는 메모리 제한을 구성하나요?

    아니요, AKS는 Cilium daemonset에서 CPU 또는 메모리 제한을 구성하지 않습니다. Cilium은 Pod 네트워킹 및 네트워크 정책 적용을 위한 중요한 시스템 구성 요소이기 때문입니다.

  • Cilium에서 제공하는 Azure CNI는 Kube-Proxy를 사용하나요?

    아니요, Cilium과 같은 네트워크 데이터부로 만들어진 AKS 클러스터는 Kube-Proxy를 사용하지 않습니다. AKS 클러스터가 Azure CNI 오버레이 또는 동적 IP 할당이 포함된 Azure CNI에 있고 Cilium에서 제공하는 Azure CNI를 실행하는 AKS 클러스터로 업그레이드되는 경우 kube-proxy 없이 새 노드 워크로드가 만들어집니다. 이 업그레이드 프로세스의 일부로 마이그레이션 워크로드도 kube-proxy 없이 실행되도록 마이그레이션됩니다.

다음 단계

AKS의 네트워킹에 대한 자세한 내용은 다음 문서를 참조하세요.