Kubernetes: Up and Running, 제3판

20장. Kubernetes 클러스터를 위한 정책 및 거버넌스

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

이 책 전체에서 우리는 각각 특정 목적을 가진 다양한 Kubernetes 리소스 유형을 소개했습니다. 단일 마이크로서비스 애플리케이션을 위한 몇 개의 리소스에서 완전한 분산 애플리케이션을 위한 수백, 수천 개의 리소스로 Kubernetes 클러스터의 리소스가 이동하는 데는 그리 오랜 시간이 걸리지 않습니다. 프로덕션 클러스터의 맥락에서 수천 개의 리소스를 관리하는 것과 관련된 문제를 상상하기란 어렵지 않습니다.

이 장에서는 정책과 거버넌스의 개념을 소개한다. 정책은 Kubernetes 리소스를 구성하는 방법에 대한 일련의 제약 및 조건입니다. 거버넌스는 모든 리소스가 최신 모범 사례를 사용하도록 보장하거나, 보안 정책을 준수하거나, 회사 규칙을 준수하는 등 Kubernetes 클러스터에 배포된 모든 리소스에 대한 조직 정책을 검증하고 시행할 수 있는 기능을 제공합니다. 어떤 경우이든, 클러스터에 정의된 모든 리소스가 조직에서 정의한 정책을 준수할 수 있도록 도구는 유연하고 확장 가능해야 합니다.

정책과 거버넌스가 중요한 이유

쿠버네티스에는 다양한 유형의 정책이 있다. 예를 들어, 네트워크폴리시는 파드가 연결할 수 있는 네트워크 서비스 및 엔드포인트를 지정할 수 있다. 파드시큐리티폴리시는 파드의 보안 요소를 세밀하게 제어할 수 있게 해준다. 둘 다 네트워크 또는 컨테이너 런타임을 구성하는 데 사용할 수 있다.

그러나 Kubernetes 리소스가 생성되기도 전에 정책을 적용하고 싶을 수도 있습니다. 이것이 바로 정책과 거버넌스가 해결하는 문제입니다. 이 시점에서 "이것이 역할 기반 접근 제어가 하는 일이 아닌가?"라고 생각할 수 있다. 그러나 이 장에서 살펴보겠지만, RBAC는 리소스 내의 특정 필드를 설정하지 못하도록 제한할 만큼 세분화되어 있지 않습니다.

다음은 클러스터 관리자가 자주구성하는 몇 가지 일반적인 정책의 예입니다:

• 모든 컨테이너는 특정 컨테이너 레지스트리에서만 제공되어야 합니다.

• 모든 파드에는 부서 이름과 연락처 정보가 레이블로 지정되어야 합니다.

• 모든 파드는 CPU와 메모리 리소스 제한이 모두 설정되어 있어야 한다.

• 모든 인그레스 호스트 이름은 클러스터 전체에서 고유해야 합니다.

• 특정 서비스를 인터넷에서 사용할 수 없도록 해서는 안 됩니다.

• 컨테이너는 권한이 있는 포트에서 수신해서는 안 됩니다.

클러스터 관리자는 클러스터의 기존 리소스를 감사하거나, 드라이런 정책 평가를 수행하거나, 일련의 조건에 따라 리소스를 변경할 수도 있습니다(예: 레이블이 없는 경우 파드에 레이블을 적용하는 것).

클러스터 관리자는 개발자가 애플리케이션을 배포하는 데 방해가 되지 않으면서 정책을 정의하고 규정 준수 감사를 수행할 수 있는 것이 매우 중요합니다. 개발자가 규정을 준수하지 않는 리소스를 생성하는 경우, 개발자가 작업을 ...