컨테이너 네트워킹에 대해 이야기할 때면 예전부터 전해 온 유명한 말이 떠오릅니다.
“세상에 컨테이너 네트워킹 같은 것은 존재하지 않습니다!” 바로 Kelsey Hightower가 한 말이죠.
그저 네트워킹만 있을 뿐입니다. 하지만 네트워크에 연결된 모든 것은 크게 변화하고 있습니다.
약 10년 전, Twelve Factor App 방법론을 통해 현대식 애플리케이션을 개발하고 구축할 수 있도록 안내하는 원칙이 도입되었습니다. 기술이 발전하면서 이러한 기본 지침은 IT 팀이 인프라, 플랫폼, 개발 환경을 관리하는 방식을 바꾸어 놓았으며, 이는 DevOps, GitOps 및 REST API의 일반화와 같은 새로운 패러다임의 원천이기도 합니다. Kubernetes 같은 컨테이너 오케스트레이터의 도입과 신속한 채택으로 실사용하는 애플리케이션 속도는 더욱 빨라졌습니다. 이제 개발자들은 그 이점을 누리고 단축된 시간을 활용할 수 있게 되었으며, 이는 비즈니스에 직접적인 영향을 미치고 있습니다.
시스코에서는 OpenDaylight 등의 프로젝트에 적극적으로 참여하고 주요 오픈 소스 프로젝트에 기여하여 이러한 변화에 아주 일찍부터 적응해왔습니다. 기술 전환을 정확히 포착하는 능력은 항상 시스코의 DNA에 있었습니다. 이러한 혁신에 발맞춰 시스코에서는 6년 전에 Cisco ACI를 출시했습니다.
하지만 현대식 데이터 센터 아키텍처로 전환할 때, 특히 환경에 Linux 컨테이너를 추가하려는 경우 요즘과 같은 새로운 클라우드 네이티브 시대에 현대식 데이터 센터 아키텍처 네트워크와 보안은 여전히 큰 우려 사항입니다. ACI 엔지니어링 팀이 지속적으로 혁신을 거듭하는 이유도 바로 여기에 있습니다.
이 글에서는 고객이 현재 직면한 과제를 알아보고, 조직이 이러한 문제를 해결하는 데 ACI Anywhere가 어떤 도움이 될 수 있는지 알려드리고자 합니다.
클라우드 네이티브 및 현재의 당면 과제
기술적인 당면 과제에 초점을 두자면, 종전의 IT 시대는 인프라, 플랫폼, 미들웨어의 기능 범위가 명확하게 구분되었지만 이제는 이러한 요소 간의 경계선이 모호해진 환경으로 뒤바뀌고 있습니다. 단순히 인프라를 넘어 코드로 규정되고 있는 이러한 방식은 소프트웨어 분산형 시스템이 인프라 구성 요소를 추상화하고, 데이터 센터의 특성을 대폭 변화시키는데 영향을 미쳤습니다. 중요한 애플리케이션을 위한 하드웨어 복원력 및 스케일업이 기본으로 내장된 설계에 의존하던 방식이 이제는 Kubernetes, Mesos 또는 Nomad 같은 온디맨드 스케일아웃 및 스테이트리스 분산형 데이터 센터 오케스트레이터 기반으로 변경되고 있는 것입니다.
인프라 측면에서 기존의 애플리케이션은 구축 프로세스에서 SDN 및 모델 중심 네트워크 같은 더 유연한 구성 요소를 이미 활용할 수 있는 상태였습니다. 이러한 여러 기술이 교차하는 길목에서, 이제 기업은 자사의 환경이 새로운 애플리케이션 요건에 적응하는 것이 현대식 데이터 센터를 성공적으로 실행하고 일관적인 운영 접근 방식을 유지하는 방법이라는 점을 깨닫게 되었습니다. 이제 운영 팀은 적재적소에 올바른 툴을 사용할 것으로 예상됩니다.
Cisco ACI는 처음부터 모든 유형의 애플리케이션 및 폼 팩터를 지원하는 유연한 SDN 레이어를 제공하기 위한 목적을 염두에 두고 개발된 제품입니다. 이러한 애플리케이션 및 폼 팩터에는 베어 메탈 서버, 하이퍼바이저, VM, 클라우드 네이티브 워크로드가 포함됩니다. ACI는 3.0 버전부터 Kubernetes 플랫폼용 CNI(Container Network Interface) 플러그인을 제공하고 있습니다. 이는 네트워크 패브릭을 컨테이너 네트워크로 확장하는 역할을 하여 기존의 네트워크 팀, SRE, 개발자가 단일 네트워크 및 보안 API와 상호 작용할 수 있도록 합니다.
그 이점을 몇 가지만 말해보자면, 현재 ACI CNI는 네트워크 중심 팀을 대상으로 다음과 같은 기능을 제공합니다.
- 컨테이너, 가상 시스템, 베어 메탈 서버를 위한 단일 오버레이 데이터 플레인.
- 컨테이너 워크로드로 확장된 ACI 화이트리스트 보안 모델. 컨테이너는 기본적으로 안전하게 구축됩니다.
- 엔드 투 엔드 네트워크 가시성 및 텔레메트리(컨테이너 네트워크 트래픽 포함).
- ToR 레이어의 네이티브 분산형 L4 로드 밸런서.
애플리케이션 및 플랫폼 중심 팀을 위한 기능:
- Kubernetes 네트워크 원칙(예: 네임스페이스 격리 및 네트워크 정책) 지원
- IPAM
- 애플리케이션별(또는 네임스페이스, 클러스터 등) 정책 기반 분산형 소스 NAT
- 보안 서비스-메시 구축
- 자동 로드 밸런싱 설정
- 추가 Prometheus 메트릭
다양한 팀에 다양한 툴이 필요한 현실
애플리케이션 기반 마이크로서비스를 구축하기 위한 리소스로 퍼블릭 클라우드를 선택하는 경우가 보편화되면서(Gartner, 설문 조사 분석: Container Adoption and Deployment, 2018), 기업이 당면하게 된 주요 과제 중 하나는 클라우드 환경 및 프라이빗 데이터 센터 전체에 걸쳐 운영 방식을 변경하는 것입니다. 일반적으로 이들은 서로 다른 두 세상에 있습니다. 종전의 데이터 센터는 권한 상태가 저장되는 모놀리식 애플리케이션으로, 인프라 패러다임이 느린 프로세스에 얽매여 있고 엄격한 SLA 요건 때문에 유연성이 제한되는 경우가 많았습니다. 이와 반대로 퍼블릭 클라우드에서의 운영은 네이티브 공급자 서비스에 크게 의존합니다. 이는 API를 통해 소비 가능하거나 일반적으로 기타 DevOps 툴을 사용하여 자동화되며, 고객이 가용성을 책임지는 구조가 아닙니다.
더 중요한 점은 네트워크 및 보안 관리의 경우 이러한 차이점이 똑같이 중요하다는 것입니다. 클라우드 네이티브 자동화 툴은 워크로드 및 클라우드 서비스를 관리하는 데만 필수적인 요소가 아니라, 네트워크 서비스 및 보안을 규모에 따라 운영하는 데에도 핵심적인 역할을 합니다. 이러한 툴은 보안 그룹, 서브넷, CIDR 같은 구문을 프로그래밍 방식으로 관리하고 컨테이너 오케스트레이터의 네트워크 레이어와 상호 작용할 수 있는 기능을 제공합니다. 이렇게 되면 클라우드 및 플랫폼 팀의 유연성과 민첩성이 대폭 향상되며 최고 수준의 애플리케이션을 구축할 수 있게 됩니다.
프라이빗 데이터 센터는 자동화 채택 및 툴 측면에서도 큰 변화가 있긴 했지만, 기본 인프라가 “클라우드 네이티브” 또는 쉽게 소모 가능한 API를 체계적으로 드러내지 않았습니다. 이렇게 되면 예를 들어 물리적 네트워크 정보와 추상화된 컨테이너 레이어의 상관관계를 분석해야 할 경우, 네트워크 팀이 효율적으로 업무를 수행하기 어렵습니다.
또 다른 운영 과제는 주로 클러스터에 있는 컨테이너 논리 경계를 관리하는 일입니다. 이로 인해 네트워크 측면에서 추가 문제가 발생하는 경우가 많습니다. 따라서 이해 관계자는 일반적으로 다음 사항을 고려해야 합니다.
- 여러 클러스터와 호스팅 환경 전 범위에 걸쳐 컨테이너를 위한 보안 통신을 실현할 방법은?
- 클러스터를 떠나는 애플리케이션 플로우를 고유하게 식별할 방법은?
- 퍼블릭 클라우드와 프라이빗 데이터 센터 간의 연결성 및 보안 정책을 관리할 수 있는 공통된 언어 또는 툴은?
ACI는 클라우드 네이티브 및 기존 애플리케이션을 위한 공통 네트워킹 레이어입니다.
ACI에는 이러한 질문에 답하는 데 필요한 기능이 포함되어 있습니다. 시스코에서는 ACI 4.1에 퍼블릭 클라우드에 대한 지원을 포함하여 네트워크 연결성 및 보안을 위한 공통 정책 모델을 제공합니다. Cisco Multi-Site Orchestrator는 단일 인터페이스에서 모든 사항을 관리할 수 있는 기능을 추가하여 네트워크 스티칭, 보안, VPN, 터널 설정을 자동화합니다. ACI CNI와 함께 이러한 기능을 사용하면 온프레미스 컨테이너, 퍼블릭 클라우드 워크로드, 현재 프라이빗 데이터 센터 내에서 지원되는 모든 기타 폼 팩터 간의 애플리케이션 플로우를 원활하게 제어할 수 있습니다.
그러나 퍼블릭 클라우드 기반 컨테이너 솔루션이 여기에 포함되지 않았으므로, 이러한 방식은 전체적인 문제를 해결할 수 없었습니다. 그래서 ACI 5.0 릴리스부터는 CNI 기능을 확장하여 클라우드에 구축된 컨테이너를 네트워크에서 가장 우선시할 수 있도록 하고자 합니다.
이를 다음 그림으로 요약하여 설명하겠습니다.
추상화된 단일 정책 모델을 활용하는 ACI를 사용하면 이제 모든 유형의 워크로드(컨테이너 포함)를 알맞게 조합할 수 있으며, 클라우드 내의 소프트웨어 구성 요소에 의존하는 동시에 온프레미스에서 항상 하드웨어에 최적화된 오버레이 네트워크에 이러한 워크로드를 연결할 수 있습니다.컨테이너 클라우드 네트워킹 솔루션은 ACI CNI 및 CSR 1000v 가상 라우터로 구성됩니다. 이 하이브리드 아키텍처는 단일 EVPN VXLAN 컨트롤 플레인에 기반하는데, 이는 원격 위치 간에 엔드포인트 정보를 안전하게 교환하여 제로 트러스트 보안 모델을 실현할 수 있도록 합니다. Kubernetes 클러스터가 클라우드에서 실행되는지 혹은 데이터 센터에서 실행되는지는 더 이상 중요하지 않습니다. 이러한 클러스터는 민첩성 및 보안을 저해하지 않고도 서로 다른 ACI 매니지드 도메인에서 상주할 수 있습니다. 온프레미스에서는 컨테이너가 APIC와 결합되어 물리적 네트워크에 대한 가시성 및 상관관계 정보를 제공하는 반면, 클라우드 내에서는 ACI 5.0 통합이 네이티브 정책을 사용하는 Cloud APIC, 프로그래밍 클라우드, 컨테이너 네트워킹 구문에 의존합니다. 이를 통해 네트워크 관리자는 모든 관련된 컨테이너 정보에 액세스할 수 있을 뿐만 아니라, 클라우드에서 클라우드까지 또는 클라우드에서 온프레미스까지 엔드 투 엔드 가시성을 실현할 수 있습니다. 이러한 방식은 다음과 같이 다중 레이어 보안도 추가로 제공합니다. 애플리케이션 레이어에서는 Kubernetes 네트워크 정책 및 컨테이너 EPG가 지원되고, 물리적 네트워크 레이어에서는 ACI 하드웨어를 사용하며, 클라우드에서는 네이티브 보안 구문을 자동화합니다.
애플리케이션 플랫폼 팀의 관점에서 보았을 때, 이러한 새로운 통합으로 인해 해당 팀은 가장 선호하는 클라우드 네이티브 툴을 사용하여 Kubernetes API와 상호 작용할 수 있는 반면, ACI CNI가 다양한 네트워크 및 보안 레이어에서 관리해야 할 구현 세부 정보는 줄어듭니다. 여기에는 노출된 서비스 NAT, EPGs, 계약 및 Kubernetes 네트워크 정책 시행을 위한 자동 로드 밸런싱이 포함됩니다. 이러한 팀에서 Kubernetes Operator 모델을 추가로 채택하고 있으므로, ACI CNI는 더 많은 자동화 기능을 제공하게 될 예정입니다. 이렇게 하면 Kubernetes Operator 구문이 ACI와 안전하게 상호 작용할 수 있고, Kubernetes 리소스와 라이프사이클, 선언 모델을 기반으로 설정 변경 사항을 적용할 수 있습니다.
아래 스크린샷에는 Cloud APIC에서 OpenShift 컨테이너에 대한 가시성이 어떻게 제공되는지 나와 있습니다.
이와 마찬가지로, 플랫폼 팀은 종전과 마찬가지로 OpenShift 명령줄을 사용하여 네임스페이스 정보를 표시합니다.
Kubernetes 배포가 너무 많이 제공되고 있으며, 클라우드 공급자도 많은 상황입니다. 이렇게 되면 여러 조합이 기하급수적으로 증가하게 됩니다. 따라서 ACI 5.0부터는 AWS EC2에서 Red Hat OCP(OpenShift Container Platform) 4.3 IPI를 지원할 수 있도록 했습니다. 향후 고객의 우선순위에 맞춰 추가적인 조합을 지원할 예정입니다.
APIC(Application Policy Infrastructure Controller) 릴리스 노트
- OSP 13에서 Red Hat Openshift 4.3 지원
- 같은 클러스터 내에서 혼합형 폼 팩터 노드(VM과 베어 메탈 서버) 실행
- Kubernetes 클러스터와 ACI 구문 간의 더욱 유연한 매핑
- 보안 Istio 서비스 메시 구축
- Prometheus 및 Kiali의 통합으로 가시성 향상
기술 세부 정보 추가
앞서 언급한 바와 같이, ACI 클라우드 CNI 초기 버전(ACI 5.0의 일부로 제공)에서는 AWS에서 Openshift 4.3 IPI 구축을 지원합니다.IPI(Installer Provisioned Infrastructure) 모드에서는 OpenShift 구축을 위한 풀 스택 자동화를 제공합니다.이 모드에서 OpenShift 설치 프로그램은 OpenShift Container Platform의 확정적인 모범 사례 구축을 활용한 인프라 프로비저닝을 포함하여 모든 설치 영역을 제어합니다. 이는 Microsoft Azure 또는 Google GCP 같은 기타 클라우드 공급자 솔루션에도 사용할 수 있습니다.
ACI CNI 설정은 OpenShift 설치 프로그램의 일부이므로 구축 시 Cloud APIC와 OpenShift 클러스터를 통합할 수 있도록 지원합니다. 이렇게 하면 클라우드 팀과 네트워크 팀은 플랫폼 팀에 대한 추가 작업을 하지 않고도 OpenShift 구문을 모두 볼 수 있습니다.
클라우드 CNI 설정은 3단계 프로세스로, 기존에 APIC(온프레미스)와 통합할 때 사용하던 것과 같은 툴 및 설정 방법을 사용합니다.
- 네트워크 또는 클라우드 팀은 acc-provision을 실행하여 CNI에 대한 샘플 YAML 설정 입력을 생성합니다.이렇게 하면 새로운 “클라우드” 특성이 제공됩니다. CNI 설정 파일은 해당 환경에 맞게 수정해야 합니다.
- 네트워크 또는 클라우드 팀은 –a 플래그와 함께 acc-provision을 실행하여 Cloud APIC에서 필요한 구문을 구축합니다. 여기에는 OpenShift 클러스터에 사용되는 ACI 테넌트는 물론 VRF, 컨텍스트 프로파일, EPG 등이 포함됩니다. 이 프로세스의 일환으로, acc-provision은 OpenShift 설치 프로그램에 필요한 추가 매니페스트 및 YAML 설정도 생성하여 CNI 구성 요소(네임스페이스, 구축, DaemonSets 등)를 구축합니다.
- 플랫폼 팀은 Openshift 설치 프로그램 설정 파일에서 ACI CNI 옵션을 사용하고 클러스터를 구축합니다.
Openshift 설치 프로그램이 작업을 완료하면 클라우드 또는 네트워크 팀은 Cloud APIC(또는 MSO)에서 EPG 및 계약을 생성하여 클라우드 기반 컨테이너가 어떤 방식으로 온프레미스에서 인프라와 다시 통신하고, 기타 VPC 또는 클라우드 공급자 환경과 통신할지 정의할 수 있습니다. 종전과 마찬가지로, 플랫폼 팀은 주석을 사용하여 OpenShift 구문을 ACI EPG에 매핑해야 합니다.
다음과 같은 네트워크 아키텍처에 따라 ACI Cloud CNI가 구축됩니다.
요약
현대적이고 강력한 네트워크는 기존의 애플리케이션과 클라우드 네이티브 애플리케이션 양쪽을 모두 지원하는 네트워크입니다. 더 중요한 것은 이러한 네트워크는 일관된 운영 접근 방식과 하이브리드 정책을 관리할 수 있는 기능을 제공해야 한다는 점입니다. ACI는 클라우드에서 컨테이너를 가장 우선시하는 ACI 5.0을 통해 바로 이러한 기능을 제공합니다. 네트워크 팀은 이러한 새로운 통합을 활용하여 데이터 센터에서 실행되는 ACI의 제어 기능을 퍼블릭 클라우드에서 실행되는 컨테이너 네트워크로 확장할 수 있으므로, ACI Anywhere 정책을 제대로 사용할 수 있게 됩니다. 그뿐만 아니라, 플랫폼 팀은 이를 통해 RedHat OpenShift IPI와 원활하게 통합되는 강력한 CNI의 이점을 활용할 수 있습니다.
이러한 기능은 이제부터 시작이므로, 향후 선보일 ACI 릴리스에서 이러한 영역에 제공될 다양한 기능을 기대해 주시기 바랍니다!
추가 리소스
- Cisco ACI와 Kubernetes 통합 설정 기술 노트
- Cisco ACI와 OpenShift 통합 설정 기술 노트
- Red Hat OpenShift Container Platform을 위한 Cisco ACI CNI 플러그인 아키텍처 및 설계 가이드
Cisco Live 리소스
DEVNET 리소스
Authors