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와 유사)
선택할 옵션을 잘 모르는 경우 "사용할 네트워크 모델 선택"을 참조하세요.
버전들
Kubernetes 버전 | 최소 Cilium 버전 |
---|---|
1.27(LTS) | 1.13.18 |
1.28(수명 종료) | 1.13.18 |
1.29 | 1.14.19 |
1.30(LTS) | 1.14.19 |
1.31 | 1.16.6 |
1.32 | 1.17.0 |
AKS 버전 관리 및 릴리스 타임라인에 대한 자세한 내용은 지원되는 Kubernetes 버전을 참조하세요.
네트워크 정책 적용
Cilium는 네트워크 정책을 적용하여 Pod 간의 트래픽을 허용하거나 거부합니다. Cilium을 사용하면 Azure Network Policy Manager 또는 Calico와 같은 별도의 네트워크 정책 엔진을 설치할 필요가 없습니다.
제한 사항
Cilium에서 제공하는 Azure CNI에는 현재 다음과 같은 제한 사항이 있습니다.
Linux에서만 사용할 수 있고 Windows에서는 사용할 수 없습니다.
네트워크 정책은 노드 또는 Pod IP에 대한 액세스를 허용하는 데 사용할
ipBlock
수 없습니다. 자세한 내용 및 권장 해결 방법은 질문과 대답을 참조하세요.Cilium 버전 1.16 이하의 경우 여러 Kubernetes 서비스에서 서로 다른 프로토콜(예: TCP 또는 UDP)과 동일한 호스트 포트를 사용할 수 없습니다(Cilium 문제 #14287).
이러한 Pod는 개별 ID가 아닌 호스트 ID를 사용하기 때문에 호스트 네트워킹(
spec.hostNetwork: true
)을 사용하는 Pod에는 네트워크 정책이 적용되지 않습니다.Cilium 엔드포인트 슬라이스는 Kubernetes 버전 1.32 이상에서 제공됩니다. Cilium 엔드포인트 조각은 Cilium 엔드포인트가 그룹화되는 방식의 구성을 지원하지 않습니다.
cilium.io/ces-namespace
를 통한 우선 순위 네임스페이스는 지원되지 않습니다.
고려 사항
네트워크 트래픽에 대한 관찰 가능성 및 FQDN(정규화된 도메인 이름) 기반 필터링 및 클러스터의 계층 7 기반 네트워크 정책과 같은 보안 기능과 같은 기능을 얻으려면 클러스터에서 고급 컨테이너 네트워킹 서비스를 사용하도록 설정하는 것이 좋습니다.
필수 조건
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 \
--name <clusterName> \
--resource-group <resourceGroupName> \
--location <location> \
--network-plugin azure \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16 \
--network-dataplane cilium \
--generate-ssh-keys
참고 항목
--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 --resource-group <resourceGroupName> --location <location> --name <vnetName> --address-prefixes <address prefix, example: 10.0.0.0/8> -o none
az network vnet subnet create --resource-group <resourceGroupName> --vnet-name <vnetName> --name nodesubnet --address-prefixes <address prefix, example: 10.240.0.0/16> -o none
az network vnet subnet create --resource-group <resourceGroupName> --vnet-name <vnetName> --name podsubnet --address-prefixes <address prefix, example: 10.241.0.0/16> -o none
--network-dataplane cilium
을 사용하여 클러스터를 만듭니다.
az aks create \
--name <clusterName> \
--resource-group <resourceGroupName> \
--location <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 \
--generate-ssh-keys
옵션 3: 노드 서브넷에서 IP 주소 할당
참고 항목
Azure CLI 버전 2.69.0 이상이 필요합니다.
az --version
을 실행하여 현재 설치된 버전을 확인합니다. 설치 또는 업그레이드해야 하는 경우 Azure CLI 설치를 참조하세요.
Cilium 데이터 평면을 사용하여 노드 서브넷으로 클러스터를 만듭니다.
az aks create \
--name <clusterName> \
--resource-group <resourceGroupName> \
--location <location> \
--network-plugin azure \
--network-dataplane cilium \
--generate-ssh-keys
자주 묻는 질문
Cilium 구성을 사용자 지정할 수 있나요?
아니요, AKS는 Cilium 구성을 관리하며 수정할 수 없습니다. 더 많은 제어가 필요한 고객은 AKS BYO CNI를 사용하고 Cilium을 수동으로 설치하는 것이 좋습니다.
Kubernetes
CiliumNetworkPolicy
리소스 대신NetworkPolicy
사용자 지정 리소스를 사용할 수 있나요?고객은 고급 컨테이너 네트워킹 서비스 기능 번들의 일부로 FQDN 필터링 및 계층 7 정책을 사용할 수 있습니다.
사용할
ClusterwideCiliumNetworkPolicy
수 있나요?ClusterwideCiliumNetworkPolicy
지원되지 않습니다.Azure 관리형 CNI에서 지원되는 Cilium 기능은 무엇입니까? 이 중 고급 컨테이너 네트워킹 서비스가 필요한 것은 무엇입니까?
지원되는 기능 w/o ACNS ACNS 포함 Cilium 엔드포인트 조각 ✔️ ✔️ K8s 네트워크 정책 ✔️ ✔️ Cilium L3/L4 네트워크 정책 ✔️ ✔️ FQDN 필터링 ❌ ✔️ L7 네트워크 정책(HTTP/gRPC/Kafka) ❌ ✔️ 컨테이너 네트워크 관찰 가능성(메트릭 및 흐름 로그) ❌ ✔️ NetworkPolicy
에 IP 주소를 허용하는ipBlock
이 있는 경우 트래픽이 차단되는 이유는 무엇인가요?Cilium에서 제공하는 Azure CNI의 제한 사항은
NetworkPolicy
'가ipBlock
Pod 또는 노드 IP를 선택할 수 없다는 것입니다.예를 들어 이
NetworkPolicy
에는ipBlock
에 대한 모든 송신을 허용하는0.0.0.0/0
이 있습니다.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로의 출구를 차단합니다.해결 방법으로
namespaceSelector
및podSelector
를 추가하여 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로의 트래픽을 허용하기 위해
NetworkPolicy
와 함께ipBlock
를 지정하는 것은 현재 불가능합니다.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의 네트워킹에 대한 자세한 내용은 다음 문서를 참조하세요.
Azure Kubernetes Service