프로덕션 환경

프로덕션 환경 (Production environment)

프로덕션 품질의 Kubernetes 클러스터는 계획과 준비가 필요해요. Kubernetes 클러스터가 중요 워크로드를 실행한다면 복원력 있도록 구성되어야 해요. 이 페이지는 프로덕션 준비가 된 클러스터를 설정하거나, 기존 클러스터를 프로덕션 용도로 승격하기 위해 취할 수 있는 단계를 설명해요.

이미 프로덕션 설정에 익숙하고 링크만 원한다면 다음 단계로 건너뛰어요.

출처: 문서

본문

프로덕션 고려 사항 (Production considerations)

일반적으로 프로덕션 Kubernetes 클러스터 환경은 개인 학습, 개발, 테스트 환경의 Kubernetes보다 요구 사항이 더 많아요. 프로덕션 환경은 많은 사용자의 안전한 접근, 일관된 가용성, 변화하는 수요에 적응할 리소스를 요구할 수 있어요.

프로덕션 Kubernetes 환경을 어디에서 실행할지(온프레미스 또는 클라우드)와 얼마나 많은 관리를 직접 하거나 남에게 맡길지 결정할 때, Kubernetes 클러스터에 대한 요구 사항이 다음 문제에 의해 어떻게 영향을 받는지 고려해요.

  • 가용성 (Availability): 단일 머신 Kubernetes 학습 환경은 단일 지점 실패가 있어요. 고가용성 클러스터를 만드는 것은 다음을 고려하는 것을 의미해요: 컨트롤 플레인을 워커 노드에서 분리하기. 여러 노드에 컨트롤 플레인 컴포넌트 복제하기. 클러스터의 API 서버에 트래픽 로드밸런싱하기. 변화하는 워크로드가 정당화함에 따라 충분한 워커 노드를 가용하게, 또는 빠르게 가용하게 만들기.
  • 규모 (Scale): 프로덕션 Kubernetes 환경이 안정적인 양의 수요를 받을 것으로 기대한다면, 필요한 용량으로 설정하고 끝낼 수 있을 거예요. 하지만 수요가 시간이 지남에 따라 성장하거나 계절이나 특별한 이벤트 같은 것에 따라 크게 변할 것으로 기대한다면, 컨트롤 플레인과 워커 노드에 대한 더 많은 요청의 증가된 압력을 해소하기 위해 확장하거나, 사용되지 않는 리소스를 줄이기 위해 축소하는 방법을 계획해야 해요.
  • 보안과 접근 관리 (Security and access management): 자체 Kubernetes 학습 클러스터에서는 전체 관리자 권한을 가져요. 하지만 중요한 워크로드가 있고 사용자가 두어 명보다 많은 공유 클러스터는 누가 무엇에 접근할 수 있는지에 대한 더 세련된 접근 방식을 요구해요. RBAC(역할 기반 접근 제어)와 다른 보안 메커니즘을 사용해 워크로드와 클러스터 자체를 안전하게 유지하면서, 사용자와 워크로드가 필요한 리소스에 접근할 수 있도록 할 수 있어요. 정책과 컨테이너 리소스를 관리해 사용자와 워크로드가 접근할 수 있는 리소스에 제한을 설정할 수 있어요.

자체 Kubernetes 프로덕션 환경을 구축하기 전에, 이 작업의 일부 또는 전체를 Turnkey Cloud Solutions 프로바이더나 다른 Kubernetes Partners에게 넘기는 것을 고려해요. 옵션에는 다음이 있어요.

  • 서버리스 (Serverless): 클러스터를 전혀 관리하지 않고 서드파티 장비에서 워크로드를 실행하기만 해요. CPU 사용량, 메모리, 디스크 요청 같은 것에 요금이 부과돼요.
  • 관리형 컨트롤 플레인 (Managed control plane): 프로바이더가 클러스터 컨트롤 플레인의 규모와 가용성을 관리하고, 패치와 업그레이드도 처리하게 해요.
  • 관리형 워커 노드 (Managed worker nodes): 요구 사항에 맞는 노드 풀을 구성한 다음, 프로바이더가 그 노드들이 가용하고 필요할 때 업그레이드를 구현할 준비가 되도록 보장하게 해요.
  • 통합 (Integration): Kubernetes를 스토리지, 컨테이너 레지스트리, 인증 방법, 개발 도구 같은 필요할 수 있는 다른 서비스와 통합하는 프로바이더가 있어요.

자체 프로덕션 Kubernetes 클러스터를 구축하든 파트너와 협력하든, 클러스터의 컨트롤 플레인, 워커 노드, 사용자 접근, 워크로드 리소스와 관련된 요구 사항을 평가하기 위해 다음 섹션을 검토해요.

프로덕션 클러스터 설정 (Production cluster setup)

프로덕션 품질의 Kubernetes 클러스터에서 컨트롤 플레인은 서로 다른 방식으로 여러 컴퓨터에 걸쳐 펼쳐질 수 있는 서비스에서 클러스터를 관리해요. 반면 각 워커 노드는 Kubernetes 파드를 실행하도록 구성된 단일 엔티티를 나타내요.

프로덕션 컨트롤 플레인 (Production control plane)

가장 단순한 Kubernetes 클러스터는 전체 컨트롤 플레인과 워커 노드 서비스가 같은 머신에서 실행돼요. Kubernetes 컴포넌트에 설명된 다이어그램에 반영된 대로 워커 노드를 추가해 그 환경을 키울 수 있어요. 클러스터가 짧은 기간 동안만 가용해야 하거나, 심각하게 잘못되면 폐기할 수 있다면, 이것이 요구 사항을 충족할 수 있어요.

하지만 더 영구적이고 고가용성인 클러스터가 필요하다면 컨트롤 플레인을 확장하는 방법을 고려해야 해요. 설계상 단일 머신에서 실행되는 원-머신 컨트롤 플레인 서비스는 고가용성이 아니에요. 클러스터를 계속 실행하고, 잘못되면 복구될 수 있음을 보장하는 것이 중요하다면 다음 단계를 고려해요.

  • 배포 도구 선택: kubeadm, kops, kubespray 같은 도구로 컨트롤 플레인을 배포할 수 있어요. 각 배포 방법으로 프로덕션 품질 배포를 위한 팁은 배포 도구로 Kubernetes 설치를 참고해요. 배포와 함께 사용할 수 있는 다양한 컨테이너 런타임이 있어요.
  • 인증서 관리: 컨트롤 플레인 서비스 사이의 보안 통신은 인증서로 구현돼요. 인증서는 배포 중 자동 생성되거나, 자체 인증 기관을 사용해 생성할 수 있어요. 자세한 내용은 PKI 인증서와 요구 사항을 참고해요.
  • apiserver용 로드밸런서 구성: 서로 다른 노드에서 실행되는 apiserver 서비스 인스턴스에 외부 API 요청을 분산하도록 로드밸런서를 구성해요. 자세한 내용은 외부 로드밸런서 생성 참고.
  • etcd 서비스 분리와 백업: etcd 서비스는 다른 컨트롤 플레인 서비스와 같은 머신에서 실행되거나, 추가 보안과 가용성을 위해 별도 머신에서 실행될 수 있어요. etcd는 클러스터 구성 데이터를 저장하므로, 필요할 때 그 데이터베이스를 복구할 수 있도록 etcd 데이터베이스 백업을 정기적으로 해야 해요. etcd 구성·사용에 대한 자세한 내용은 etcd FAQ를 참고해요. Kubernetes용 etcd 클러스터 운영과 kubeadm으로 고가용성 etcd 클러스터 설정 참고.
  • 여러 컨트롤 플레인 시스템 생성: 고가용성을 위해 컨트롤 플레인은 단일 머신으로 제한되어서는 안 돼요. 컨트롤 플레인 서비스가 init 서비스(예: systemd)에 의해 실행된다면, 각 서비스는 최소 세 머신에서 실행되어야 해요. 하지만 컨트롤 플레인 서비스를 Kubernetes에서 파드로 실행하면 요청한 복제된 수의 서비스가 항상 가용하도록 보장돼요. 스케줄러는 장애 허용적이어야 하지만 고가용성일 필요는 없어요. 일부 배포 도구는 Kubernetes 서비스의 리더 선출을 위해 Raft 합의 알고리즘을 설정해요. 주 서비스가 사라지면 다른 서비스가 스스로를 선출해 인계받아요.
  • 여러 영역에 걸치기: 클러스터를 항상 가용하게 유지하는 것이 중요하다면, 클라우드 환경에서 영역(zone)이라 하는 여러 데이터 센터에 걸쳐 실행되는 클러스터를 만드는 것을 고려해요. 영역 그룹을 리전(region)이라고 해요. 같은 리전의 여러 영역에 클러스터를 펼치면, 한 영역이 사용 불가가 되어도 클러스터가 계속 기능할 가능성을 높일 수 있어요. 자세한 내용은 여러 영역에서 실행 참고.
  • 지속적 기능 관리: 클러스터를 오래 유지할 계획이라면, 그 건강과 보안을 유지하기 위해 해야 할 작업들이 있어요. 예를 들어 kubeadm으로 설치했다면 인증서 관리와 kubeadm 클러스터 업그레이드를 돕는 지침이 있어요. 더 긴 Kubernetes 관리 작업 목록은 클러스터 관리 참고.

컨트롤 플레인 서비스를 실행할 때 사용 가능한 옵션에 대해 배우려면 kube-apiserver, kube-controller-manager, kube-scheduler 컴포넌트 페이지를 참고해요. 고가용성 컨트롤 플레인 예시는 고가용성 토폴로지 옵션, kubeadm으로 고가용성 클러스터 생성, Kubernetes용 etcd 클러스터 운영 참고. etcd 백업 계획 만들기에 대한 정보는 etcd 클러스터 백업을 참고해요.

프로덕션 워커 노드 (Production worker nodes)

프로덕션 품질 워크로드는 복원력이 있어야 하고, 그들이 의존하는 모든 것도 복원력이 있어야 해요(예: CoreDNS). 자체 컨트롤 플레인을 관리하든 클라우드 프로바이더가 관리하게 하든, 여전히 워커 노드를 어떻게 관리할지 고려해야 해요.

  • 노드 구성: 노드는 물리 또는 가상 머신일 수 있어요. 자체 노드를 만들고 관리하려면 지원되는 운영체제를 설치한 다음 적절한 노드 서비스를 추가·실행할 수 있어요. 고려 사항: 적절한 메모리, CPU, 디스크 속도와 스토리지 용량을 가짐으로써 노드를 설정할 때 워크로드의 요구를 고려. 일반 컴퓨터 시스템으로 충분한지, GPU 프로세서, Windows 노드, VM 격리가 필요한 워크로드가 있는지.
  • 노드 검증: 노드가 Kubernetes 클러스터에 합류하기 위한 요구 사항을 충족하는지 확인하는 방법에 대한 정보는 유효한 노드 설정 참고.
  • 클러스터에 노드 추가: 자체 클러스터를 관리한다면, 자체 머신을 설정하고 수동으로 추가하거나 클러스터의 apiserver에 스스로 등록하게 함으로써 노드를 추가할 수 있어요. 이런 방식으로 Kubernetes를 설정해 노드를 추가하는 방법은 노드 섹션 참고.
  • 노드 확장: 클러스터가 결국 필요할 용량을 확장할 계획을 가져요. 실행해야 할 파드와 컨테이너 수에 따라 몇 개의 노드가 필요한지 결정하는 데 도움이 되는 대형 클러스터 고려 사항 참고. 자체 노드를 관리한다면 이것은 자체 물리 장비 구매·설치를 의미할 수 있어요.
  • 노드 오토스케일링: 노드와 그것이 제공하는 용량을 자동으로 관리하기 위해 사용 가능한 도구에 대해 노드 오토스케일링 읽기.
  • 노드 상태 확인 설정: 중요한 워크로드의 경우, 노드와 그 노드에서 실행되는 파드가 건강한지 확인하고 싶을 거예요. Node Problem Detector 데몬을 사용해 노드가 건강한지 보장할 수 있어요.

프로덕션 사용자 관리 (Production user management)

프로덕션에서는 사용자 또는 소규모 그룹이 클러스터에 접근하는 모델에서 잠재적으로 수십 또는 수백 명이 접근하는 모델로 이동하고 있을 수 있어요. 학습 환경이나 플랫폼 프로토타입에서는 모든 작업에 단일 관리자 계정이 있을 수 있어요. 프로덕션에서는 서로 다른 네임스페이스에 대해 서로 다른 수준의 접근을 가진 더 많은 계정을 원할 거예요.

프로덕션 품질 클러스터를 맡는다는 것은 다른 사용자의 접근을 선택적으로 허용하는 방법을 결정한다는 뜻이에요. 특히 클러스터에 접근을 시도하는 사람들의 신원을 검증하는 전략(인증/authentication)과 그들이 요구하는 것을 할 권한이 있는지 결정하는 전략(인가/authorization)을 선택해야 해요.

  • 인증 (Authentication): apiserver는 클라이언트 인증서, 베어러 토큰, 인증 프록시, HTTP basic auth로 사용자를 인증할 수 있어요. 사용할 인증 방법을 선택할 수 있어요. 플러그인을 사용해 apiserver는 LDAP나 Kerberos 같은 조직의 기존 인증 방법을 활용할 수 있어요. 이 서로 다른 Kubernetes 사용자 인증 방법에 대한 설명은 인증 참고.
  • 인가 (Authorization): 일반 사용자를 인가할 때는 RBAC와 ABAC 인가 사이에서 선택할 가능성이 높아요. 사용자 계정 인가의 서로 다른 모드(그리고 클러스터에 대한 서비스 계정 접근)를 검토하려면 인가 개요 참고. RBAC(역할 기반 접근 제어): 특정 권한 집합을 인증된 사용자에게 허용함으로써 클러스터에 대한 접근을 할당하게 해줘요. 권한은 특정 네임스페이스(Role) 또는 클러스터 전체(ClusterRole)에 대해 할당될 수 있어요. 그런 다음 RoleBinding과 ClusterRoleBinding을 사용해 그 권한을 특정 사용자에 연결할 수 있어요. ABAC(속성 기반 접근 제어): 클러스터의 리소스 속성에 기반한 정책을 만들고, 그 속성에 기반해 접근을 허용하거나 거부하게 해줘요. 정책 파일의 각 줄은 버전 속성(apiVersion과 kind)과, 대상(사용자 또는 그룹), 리소스 속성, 비리소스 속성(/version 또는 /apis), readonly를 일치시키는 spec 속성 맵을 식별해요. 자세한 내용은 예시 참고.

프로덕션 Kubernetes 클러스터에서 인증·인가를 설정하는 사람으로서 고려할 몇 가지 사항이 있어요.

  • 인가 모드 설정: Kubernetes API 서버(kube-apiserver)가 시작될 때, 지원되는 인가 모드는 --authorization-config 파일 또는 --authorization-mode 플래그로 설정해야 해요. 예를 들어 kube-adminserver.yaml 파일(/etc/kubernetes/manifests)의 그 플래그는 Node,RBAC으로 설정될 수 있어요. 이것은 인증된 요청에 대해 Node와 RBAC 인가를 허용해요.
  • 사용자 인증서와 역할 바인딩 생성 (RBAC): RBAC 인가를 사용한다면 사용자는 클러스터 CA가 서명할 수 있는 CertificateSigningRequest(CSR)를 만들 수 있어요. 그런 다음 각 사용자에 Roles와 ClusterRoles를 바인딩할 수 있어요. 자세한 내용은 인증서 서명 요청 참고.
  • 속성을 조합한 정책 생성 (ABAC): ABAC 인가를 사용한다면 선택된 사용자나 그룹이 특정 리소스(예: 파드), 네임스페이스, apiGroup에 접근하도록 승인하는 정책을 형성하도록 속성 조합을 할당할 수 있어요. 자세한 내용은 예시 참고.
  • Admission 컨트롤러 고려: API 서버를 통해 들어올 수 있는 요청에 대한 추가 형태의 인가에는 Webhook 토큰 인증이 있어요. Webhook과 다른 특별한 인가 유형은 API 서버에 Admission 컨트롤러를 추가해 활성화해야 해요.

워크로드 리소스에 제한 설정

프로덕션 워크로드의 수요는 Kubernetes 컨트롤 플레인 안팎으로 압력을 일으킬 수 있어요. 클러스터 워크로드의 요구 사항에 맞춰 설정할 때 다음 항목을 고려해요.

  • 네임스페이스 제한 설정: 메모리와 CPU 같은 것에 네임스페이스별 쿼터를 설정해요. 자세한 내용은 메모리, CPU, API 리소스 관리 참고.
  • DNS 수요 준비: 워크로드가 대규모로 확장될 것으로 기대한다면, DNS 서비스도 함께 확장될 준비가 되어야 해요. 클러스터의 DNS 서비스 오토스케일링 참고.
  • 추가 서비스 계정 생성: 사용자 계정은 사용자가 클러스터에서 할 수 있는 것을 결정하고, 서비스 계정은 특정 네임스페이스 안에서 파드 접근을 정의해요. 기본적으로 파드는 네임스페이스의 기본 서비스 계정을 취해요. 새 서비스 계정 생성에 대한 정보는 서비스 계정 관리 참고. 예를 들어, 파드가 특정 컨테이너 레지스트리에서 이미지를 가져올 수 있게 하는 시크릿을 추가하고 싶을 수 있어요. 예시는 파드용 서비스 계정 구성 참고. 서비스 계정에 RBAC 권한을 할당하고 싶을 수도 있어요. 자세한 내용은 ServiceAccount 권한 참고.

다음 단계

더 알아보기 (Learn more)