Production-Ready env

HA master nodes

• 최소 3대의 컨트롤 플레인 노드 사용
• 컨트롤 플레인 노드 앞에 로드 밸런서를 구성해야 함.
• 마스터 노드 장애가 발생하면 이를 대체하기 위해 새 노드가 자동으로 생성될 수 있어야 함.

적절한 노드 크기

• 예상되는 워크로드 리소스 수요에 따라 노드 크기를 조정해야 함.
• ingress controller 나 metrics server와 같이 시스템 크리티컬 POD는 점 더 많은 cpu와 memory를 할당하여야 함.
• 특정 임계값에 도달하면 자동 확장 그룹과 클러스터 자동 확장 처리를 사용하여 자동으로 노드를 추가함.

Private Network

• 인터넷에 액세스 할 수 없는 private subnet에 k8s cluster를 배치함.
• kube-apiserver를 접그하는 클라이언트는 알려진 IP 범위로 제한하고 인증 및 권한 부여 정책을 통해 안전하게 보호해야 함.
• 노드간 private network를 사용하여 보호. 트래픽 도청이나 변조를 방지할 수 있음.

보안 조치

• RBAC 정책을 사용하여 필요한 것에 대해서만 사용자 액세스를 제한함.
  cluster-admin 과 같은 광범위한 권한은 제한해야 함.
• 좁은 범위의 권한을 사용하여 개발자, 운영팀 등의 역할을 만듬.
• RBAC 정책을 지속적으로 검토하고 개선해야 함.

네트워크 정책

• 네트워크 정책을 활용하여 포드 간 및 포드 간 외부 통신을 제한해야 함.
• 기본적으로는 deny 정책을 설정하고 필요에 따라 선택적으로 트래픽을 허용하는 방향으로 가야함.
• 광범위한 보안을 위해 네임스페이스 수준 정책을 사용함. 세부적인 제어늘 Pod 수준 정책을 사용함.

암호화

• k8s secret과 민감한 데이터를 보호하기 위해 ETCD 암호화를 활성화 해야 함.
• secret은 Vault by Hashicorp와 같은 타사 서비스를 이용하는 것이 좋음.
• k8s 구성요소간 mTLS를 사용하여 전송 중인 데이터를 암호화함.
• Edge에서 SSL/TLS 종료를 위해 Nginx와 같은 reverse proxy를 사용함

감사

• 모든 API 요청과 사용자 작업을 추적하기 위해 감사 로그를 활성화 해야 함.
• 모니터링 및 분석을 위해 감사 로그를 SIEM으로 전달
• 고위험 RBAC 권한과 같은 의심스러운 활동에 대해 경고해야 함.

스캐닝 및 모니터링

• kube-bench와 같은 도구를 사용하여 Kubernetes의 잘못된 구성을 지속적으로 검사합니다.
• Sysdig Falco와 같은 솔루션을 사용하여 클러스터에 위협과 이상 현상이 있는지 모니터링하세요.

클러스터, 노드, 포드 모니터링

• Kubernetes 클러스터, 노드 및 Pod의 CPU, 메모리, 디스크 및 네트워크 사용량을 모니터링합니다. 이를 통해 가동 중단이 발생하기 전에 리소스 부족이나 병목 현상을 포착할 수 있습니다. 널리 사용되는 도구로는 Prometheus와 Grafana가 있습니다.
• 포드 가동 시간 및 재시작 횟수를 추적합니다. 자주 다시 시작하면 불안정할 수 있습니다.
• 노드 작동 중지, 키 포드 제거 또는 포드 자주 다시 시작에 대한 알림을 설정하세요. 문제가 발생하면 신속하게 알림을 받으세요.

로그 집계

• Elasticsearch, Fluentd 또는 Datadog과 같은 로그 집계 도구를 사용하여 클러스터 구성 요소 전체의 로그를 중앙 집중화하고 색인화합니다. 이는 로그를 검색할 수 있는 단일 위치를 제공합니다.
• 노드 및 Pod 수준에서 로그 수집을 활성화합니다. 애플리케이션 로그와 Kubernetes 시스템 로그를 캡처합니다.
• 문제를 추적하려면 포드 이름, 네임스페이스 등의 메타데이터를 로그에 추가하세요.

경고

• 임계값을 초과하는 로그 오류 또는 사용량 측정항목에 의해 트리거되는 알림 규칙을 설정합니다. 예를 들어 노드의 CPU 또는 메모리 사용량이 급증하면 경고합니다.
• 이메일, Slack 또는 PagerDuty와 같은 다양한 알림 채널을 구성합니다. 중요한 경보는 즉시 대기 중인 직원에게 전달되어야 합니다.
• 일반적인 경고와 권장 대응을 문서화합니다. 이렇게 하면 경고가 발생할 때 문제 해결 속도가 빨라집니다.
• 경고를 자주 테스트하여 알림이 작동하는지 확인하세요. 신뢰할 수 있는 경고를 통해 정전이 인지되지 못하는 일이 발생하지 않도록 방지합니다. 강력한 클러스터 모니터링, 로그 집계 및 알림 기능을 통해 운영자는 Kubernetes 클러스터의 상태에 대한 심층적인 가시성을 확보합니다. 문제가 사용자에게 영향을 미치기 전에 신속하게 감지하고 디버깅할 수 있습니다.

격리를 위한 네임스페이스

Kubernetes 네임스페이스는 애플리케이션, 팀 또는 환경 그룹 간의 격리를 제공합니다. 네임스페이스는 다음과 같은 이유로 프로덕션 준비 Kubernetes 환경의 중요한 부분입니다.

• 별도의 환경: 네임스페이스는 개발, 스테이징 및 프로덕션 환경을 분리하여 서로 영향을 주지 않도록 할 수 있습니다. 예를 들어, 개발자가 prod의 애플리케이션에 영향을 주지 않고 새로운 기능을 테스트할 수 있도록 dev 네임스페이스를 가질 수 있습니다.

• 액세스 제어: 네임스페이스를 사용하면 해당 네임스페이스 내의 리소스에 액세스, 수정 또는 삭제할 수 있는 권한을 설정할 수 있습니다. 예를 들어 프로덕션 네임스페이스에 대한 액세스를 소규모 관리자 팀으로 제한하고 개발 네임스페이스는 모든 개발자에게 공개할 수 있습니다.

리소스 할당량 및 한도

• 공유 Kubernetes 클러스터에서는 단일 애플리케이션이나 팀이 공정한 리소스 공유 이상을 사용하지 못하도록 방지하는 것이 중요합니다. 리소스 할당량 및 한도를 사용하면 네임스페이스 및 포드/컨테이너별로 리소스 사용량을 제한할 수 있습니다.

• 네임스페이스 할당량을 설정하면 단일 팀이 다른 팀의 성능을 저하시킬 수 있는 포드, 서비스 등을 무제한으로 생성할 수 없습니다. 네임스페이스당 총 CPU, 메모리, 포드 수, 서비스, 영구 볼륨 요청 등을 제한할 수 있습니다.

배포 및 롤백

상태 점검 및 자동 수리

활성 및 준비 상태 프로브로 알려진 Kubernetes 상태 확인을 사용하면 애플리케이션의 상태를 모니터링하고 문제가 발생할 때 컨테이너를 다시 시작하거나 재배포할 수 있습니다. 이는 자동화된 자가 치유 기능을 제공합니다.

서비스 우선 순위(QoS)

Kubernetes는 개별 Pod가 수신하는 QoS(서비스 품질)를 제어하는 ​​기능을 제공합니다. 이를 통해 Pod가 특정 양의 컴퓨팅 리소스를 확보하고, 시끄러운 이웃 문제를 방지하고, 중요한 시스템 서비스의 우선순위를 지정할 수 있습니다. QoS 제공에 도움이 되는 두 가지 주요 기능

• 포드 우선순위: 'priorityClassName' 필드를 포드에 설정하여 우선순위 클래스를 할당할 수 있습니다. 우선순위 클래스의 범위는 0~1000000이며 값이 높을수록 우선순위가 높습니다. 기본적으로 Pod에는 우선순위 클래스가 없으며 동일하게 취급됩니다. 우선순위를 설정하면 모니터링 에이전트와 같은 중요한 Pod가 덜 중요한 Pod보다 예약 우선순위를 갖게 됩니다. 우선순위는 선점에도 영향을 미칩니다. 우선순위가 낮은 포드는 보류 중인 우선순위가 높은 포드를 위한 공간을 확보하기 위해 선점됩니다.

• 리소스 예약 리소스 요청 및 제한은 포드의 모든 컨테이너에 대해 구성되어야 합니다. 요청 금액은 해당 컨테이너에 대해 지정된 컴퓨팅 리소스를 예약하고 보장합니다. 이 제한은 최대 사용량 임계값을 설정합니다. 각 컨테이너에 대한 리소스를 예약하면 기아 교착 상태를 방지하고 클러스터 리소스의 최소 공유를 보장할 수 있습니다. 컨테이너당 사용량을 제한하면 단일 프로세스가 용량을 장악하는 것을 방지할 수 있습니다. 우선순위 클래스와 리소스 예약을 함께 사용하면 Pod 수준 QoS 기능을 제공하여 Kubernetes에서 중요한 비즈니스 서비스를 안정적으로 제공할 수 있습니다.

자동 확장

Kubernetes는 현재 워크로드 수요에 맞게 Pod 및 노드 수를 일치시키는 자동 확장 기능을 제공합니다. 이를 통해 트래픽이 급증하는 동안 클러스터를 확장하고 수요가 감소하면 다시 축소할 수 있습니다.

수평형 포드 자동 확장 처리(HPA)
HPA(Horizontal Pod Autoscaler)는 관찰된 CPU 사용률 또는 기타 선택 지표를 기반으로 배포 또는 복제본 세트의 Pod 수를 자동으로 조정합니다. HPA는 로드 변경을 처리할 수 있는 적절한 Pod를 확보하고 수요가 낮을 때 유휴 Pod가 과도하게 프로비저닝되는 것을 방지합니다. HPA를 설정하려면 최소 및 최대 포드 복제본 수와 조정을 트리거할 CPU 사용률을 정의합니다. 그런 다음 Kubernetes 컨트롤러는 관찰된 측정항목을 기반으로 해당 범위 사이의 Pod 수를 자동으로 조정합니다.

클러스터 자동 확장 처리
HPA가 포드 크기 조정을 처리하는 반면 Cluster Autoscaler는 특히 클러스터의 자동 노드 크기 조정을 처리합니다. 보류 중인 포드 리소스 요청에 따라 노드를 자동으로 추가하거나 제거합니다. HPA와 마찬가지로 Cluster Autoscaler는 수요가 급증하는 동안 새 포드에 적절한 노드를 사용할 수 있도록 보장합니다. 또한 비용을 최적화하기 위해 활용도가 낮은 불필요한 노드를 제거합니다. Cluster Autoscaler는 클러스터에 별도로 배포되어야 하며 자동 크기 조정이 필요한 노드 그룹을 가리켜야 합니다. 리소스 활용도 및 스케일인/스케일아웃 지연과 같은 임계값도 구성할 수 있습니다. HPA와 Cluster Autoscaler는 함께 포드 및 노드에 대한 포괄적인 자동 크기 조정 기능을 제공합니다. 두 가지를 모두 구성하면 진정한 자체 관리형 Kubernetes 클러스터를 만드는 데 도움이 됩니다.

백업 및 재해 복구

비즈니스 연속성을 보장하려면 프로덕션 Kubernetes 클러스터에 강력한 백업 및 재해 복구 기능이 필요합니다. 다음은 몇 가지 주요 고려 사항입니다.

클러스터 스냅샷 Kubernetes 클러스터의 정기적인 스냅샷을 찍어 특정 시점의 워크로드 및 리소스 상태를 캡처합니다. 최적의 데이터 보호를 위해 스냅샷을 오프사이트에 저장하세요. 스냅샷을 사용하면 문제가 발생한 경우 클러스터를 이전에 알려진 양호한 상태로 복원할 수 있습니다.
오프사이트 백업 스토리지 스냅샷 외에도 중요한 데이터와 애플리케이션 구성을 원격 오프사이트 스토리지 위치에 백업합니다. 이는 기본 클러스터에 치명적인 오류나 중단이 발생할 경우 추가 보호 계층을 제공합니다. 백업 데이터용으로 설계된 안전하고 탄력적인 오프사이트 스토리지 서비스를 선택하세요.
다중 지역 클러스터 중복성을 극대화하려면 여러 지역 또는 클라우드 제공업체에서 Kubernetes를 실행하세요. 이는 지역별 오류로부터 보호합니다. 지속적인 가용성을 위해 중요한 애플리케이션을 여러 지역에 복제할 수 있습니다. 그러면 글로벌 로드 밸런싱이 가장 가까운 정상 클러스터로 트래픽을 전달합니다. 다중 지역 아키텍처는 Kubernetes 복원성을 크게 강화합니다. 포괄적인 스냅샷 생성, 오프사이트 백업 및 다중 지역 클러스터를 통해 Kubernetes는 중단, 재해, 데이터 손실 등으로부터 강력한 복구를 제공할 수 있습니다. 백업 및 재해 복구를 신중하게 계획하면 Kubernetes의 애플리케이션을 계속 사용할 수 있습니다.