사용 시나리오
이제 결정 기준에 대한 장단점을 설정했으므로 몇 가지 시나리오를 살펴보는 것이 가장 좋습니다.
개발
제한된 IP 주소 공간에서 여러 기능의 개발을 수용하는 것은 어려울 수 있습니다. Kubenet은 주소 공간의 보존을 염두에 두고 설계되었으므로 개발 또는 실험 환경에 적합합니다.
다음 중 하나 이상이 사실이 아닌 경우 Azure CNI 네트워킹을 사용하는 개발 환경을 선택하는 것이 좋습니다.
- 실험적 또는 개발 중인 기능은 Azure Container Instances가 포함된 가상 노드에서 제공하는 신속한 크기 조정 기능이 필요하지 않습니다.
- Pod 통신을 위한 추가 홉으로 인해 발생하는 환경의 약간의 대기 시간은 허용됩니다.
- 개발 환경에서 경로 테이블 및 UDR을 유지 관리하는 운영 오버헤드는 허용됩니다.
- 개발 환경은 Linux 기반 노드 풀만 지원합니다.
kubenet을 사용하면 AKS 클러스터를 만들 때마다 Azure 플랫폼이 자동으로 가상 네트워크 리소스를 만들고 구성합니다. 가상 네트워크 리소스를 수동으로 만들기 및 구성하고 만들 때 해당 리소스에 연결할 수도 있습니다. 그러나 Azure 관리 네트워크 리소스를 변경하는 것은 지원되지 않습니다.
생산
kubenet이 프로덕션에 허용되는 네트워킹 옵션이 되지 못하게 하는 몇 가지 요인이 있다는 점을 유념해야 합니다. Kubenet은 개발 중인 소규모 애플리케이션의 프로토타입을 만들고 테스트하는 빠른 방법으로 뛰어납니다.
대신 Azure CNI는 다음을 포함하는 구성 가능한 네트워킹 옵션으로 인해 프로덕션 환경에 더 적합합니다.
- 대기 시간 감소:
- Azure Container Instances를 사용하여 Virtual Nodes를 통한 신속한 크기 조정 기능입니다.
- 직접 주소 지정이 가능한 Pod는 클러스터 외부에서 실행되는 서비스에 대한 연결을 간소화합니다.
- 고급 네트워크 토폴로지 및 관련 기능을 지원합니다.
사용 사례에 하나 이상의 기능이 필요한 경우 개발 환경에 Azure CNI를 사용하도록 옵트인할 수도 있습니다. 예를 들어 Windows Server 기반 노드가 필요한 경우 개발 및 프로덕션 클러스터 모두에 Azure CNI를 사용해야 합니다. 이 선택으로 인해 전문가가 필요한 더 많은 네트워크 토폴로지 계획이 필요하다는 점을 유념해야 합니다.