최신 애플리케이션 플랫폼 솔루션 관리

  • 아티클

클라우드 채택 프레임워크는 클라우드 포트폴리오의 거버넌스를 체계적이고 점진적으로 개선하는 방법론을 제공합니다. 이 문서에서는 거버넌스 접근 방식을 Azure 또는 다른 퍼블릭 또는 프라이빗 클라우드에 배포된 Kubernetes 클러스터로 확장하는 방법을 보여줍니다.

초기 거버넌스 기반

거버넌스는 거버넌스 MVP라고도 하는 초기 거버넌스 파운데이션으로 시작합니다. 이 파운데이션은 클라우드 환경 전반에 거버넌스를 제공하는 데 필요한 기본 Azure 제품을 배포합니다.

초기 거버넌스 파운데이션은 거버넌스의 다음과 같은 측면에 중점을 둡니다.

  • 기본 하이브리드 네트워크 및 연결.
  • ID 및 액세스 제어를 위한 Azure RBAC(역할 기반 액세스 제어).
  • 리소스를 일관되게 식별하기 위한 명명 및 태그 지정 표준.
  • 리소스 그룹, 구독 및 관리 그룹을 사용하는 리소스 구성.
  • 거버넌스 정책을 적용하기 위한 Azure Policy 및 Azure Blueprints.

초기 거버넌스 파운데이션의 이러한 기능을 사용하여 최신 애플리케이션 플랫폼 솔루션 인스턴스를 제어할 수 있습니다. 하지만 먼저 컨테이너에 Azure Policy를 적용할 수 있도록 초기 파운데이션에 몇 가지 구성 요소를 추가해야 합니다. 구성이 완료되면 Azure Policy 및 초기 거버넌스 파운데이션을 사용하여 다음 유형의 컨테이너를 제어할 수 있습니다.

거버넌스 분야 확장

초기 거버넌스 파운데이션을 사용하여 다양한 거버넌스 분야를 확장하면 모든 Kubernetes 인스턴스에서 일관되고 안정적인 배포 접근 방식을 보장할 수 있습니다.

Kubernetes 클러스터의 거버넌스는 5가지 고유한 관점으로 살펴볼 수 있습니다.

리소스 관리 거버넌스

첫 번째는 Azure 리소스 관점입니다. 모든 클러스터가 조직의 요구 사항을 준수하는지 확인합니다. 여기에는 네트워크 토폴로지, 프라이빗 클러스터, SRE 팀의 Azure RBAC 역할, 진단 설정, 지역 가용성, 노드 풀 고려 사항, Azure Container Registry 거버넌스, Azure Load Balancer 옵션, AKS 추가 기능, 진단 설정 등의 개념이 포함됩니다. 이 거버넌스는 조직 내 클러스터의 "모양과 느낌" 및 "토폴로지"에서 일관성을 보장합니다. 또한 설치해야 하는 보안 에이전트 및 구성 방법과 같은 사후 클러스터 배포 부트스트랩으로 확장해야 합니다.

Snowflake 클러스터는 그 어떤 중앙 용량에서도 제어하기 어렵습니다. 정책을 균일하게 적용할 수 있도록 클러스터 간 불일치를 최소화하고 비정상적인 클러스터를 사용하지 마세요. 비정상 클러스터는 탐지 가능합니다. 여기에는 ARM, Bicep 또는 Terraform과 같은 클러스터를 배포하는 데 사용되는 기술도 포함될 수 있습니다.

관리 그룹/구독 수준에서 적용되는 Azure Policy는 이러한 고려 사항을 많이 제공하는 데 도움이 될 수 있지만 전부 제공하지는 않습니다.

Kubernetes 워크로드 거버넌스

Kubernetes 자체는 플랫폼이므로 두 번째는 클러스터 내에서 발생하는 일의 거버넌스입니다. 여기에는 네임스페이스 지침, 네트워크 정책, Kubernetes RBAC, 제한 및 할당량과 같은 것들이 포함됩니다. 이 거버넌스는 워크로드에 적용되고, 클러스터에는 덜 적용됩니다. 모든 워크로드는 서로 다른 비즈니스 문제를 해결하고 다양한 기술을 통해 다양한 방식으로 구현되기 때문에 같은 워크로드는 하나도 없습니다. "모든 상황에 맞는 단일 크기" 거버넌스 사례가 많지 않을 수도 있지만, OCI 아티팩트 생성/소비, 공급망 요구 사항, 공용 컨테이너 레지스트리 사용, 이미지 격리 프로세스, 배포 파이프라인 거버넌스와 관련된 거버넌스를 고려해야 합니다.

실행 가능한 경우 일반적인 도구 및 패턴에 대해서도 표준화하는 것이 좋습니다. Helm, 서비스 메시, 수신 컨트롤러, GitOps 연산자, 영구 볼륨 등과 같은 기술에 대한 권장 사항을 제시합니다. Pod 관리 ID 사용 및 Key Vault에서 비밀 소싱에 대한 거버넌스도 여기에 포함됩니다.

워크로드 소유자가 제품 개선에 필요한 메트릭 및 데이터에 적절하게 액세스할 수 있도록 하는 동시에 클러스터 운영자가 서비스 제품을 개선하기 위해 시스템 원격 메트릭에 액세스할 수 있도록 보장하여 원격 분석 데이터 액세스와 관련된 큰 기대를 심어줍니다. 데이터는 종종 둘 간에 상관 관계를 지정해야 하며, 필요할 때 적절한 액세스를 보장하도록 거버넌스 정책이 마련되어 있어야 합니다.

클러스터 수준에서 적용되는 AKS용 Azure Policy는 이러한 기능 중 일부를 제공하지만, 전부 제공하지는 않습니다.

클러스터 운영자 역할(DevOps, SRE)

세 번째는 클러스터 운영자 역할에 대한 거버넌스입니다. SRE 팀이 클러스터와 어떻게 상호 작용하나요? 해당 팀과 워크로드 팀은 어떤 관계에 있나요? 두 팀이 똑같나요? 클러스터 운영자는 클러스터에 액세스하는 방법, 클러스터에 액세스하는 위치, 클러스터에 대한 권한 및 권한이 할당된 시간과 같은 클러스터 심사 활동에 대해 명확하게 정의된 플레이북이 있어야 합니다. 이 컨텍스트에서 워크로드 운영자와 클러스터 운영자의 거버넌스 설명서, 정책 및 교육 자료에 차이를 둡니다. 조직에 따라 똑같을 수도 있습니다.

워크로드당 클러스터 또는 클러스터당 여러 워크로드

네 번째는 다중 테넌트 거버넌스입니다. 즉, 정의에 따라 클러스터는 동일한 워크로드 팀이 소유한 애플리케이션의 "그룹화"를 포함하고 관련 워크로드 구성 요소의 단일 세트를 나타내야 합니다. 또는 설계상 클러스터는 기본적으로 여러 개의 서로 다른 워크로드 및 워크로드 소유자가 있는 다중 테넌트여야 하고, 조직 내의 관리형 서비스 제품처럼 실행되고 제어되어야 합니다. 거버넌스 전략은 각각에 대해 뚜렷하게 다르며, 따라서 선택한 전략이 적용되도록 제어해야 합니다. 두 모델을 모두 지원해야 하는 경우 어떤 유형의 클러스터에 어떤 정책이 적용되는지 거버넌스 계획을 명확하게 정의해야 합니다.

이 선택은 인력, 예산 및 혁신에 상당한 영향을 미치므로 전략 단계에서 이루어졌어야 합니다.

최신 활동 유지

다섯 번째는 노드 이미지 새로 고침(패치) 및 Kubernetes 버전 관리와 같은 운영에 관한 것입니다. 노드 이미지 업그레이드, 적용된 패치 추적, Kubernetes 및 AKS 일반 취약성 및 노출에 대한 수정 계획을 추적하고 결합하는 사람은 누구인가요? 워크로드 팀은 클러스터 업그레이드 후 솔루션이 작동하는지 확인하는 유효성 검사에 관여해야 하며, 클러스터가 최신 버전이 아닌 경우 Azure 지원에서 제외됩니다. AKS에서 "최신 상태 유지" 활동과 관련된 강력한 거버넌스를 유지하는 것은 Azure의 대부분의 다른 플랫폼에서 매우 중요합니다. 따라서 클러스터를 최신 상태로 유지하기 위한 워크로드 유효성 검사를 위해 적어도 매달 애플리케이션 팀과 매우 긴밀하게 협력하고 시간을 투자해야 합니다. Kubernetes에 종속된 모든 팀이 이 지속적인 활동의 요구 사항과 비용을 이해하도록 해야 하며, 이 활동은 플랫폼에 Kubernetes가 있는 한 지속될 것입니다.

보안 기준

다음 모범 사례를 보안 기준에 추가하여 AKS 클러스터의 보안을 생각해 볼 수 있습니다.

ID

Kubernetes 클러스터에서 일관된 ID 및 액세스 관리를 보장하기 위해 ID 기준에 적용할 수 있는 많은 모범 사례가 있습니다.

다음 단계: 최신 애플리케이션 플랫폼 솔루션 관리

다음 문서에서는 클라우드 채택 시나리오를 성공적으로 진행할 수 있도록 클라우드 채택 과정의 특정 지점에 대한 지침을 제공합니다.