Kubernetes를 사용한 다중 환경 (스테이징, QA, 프로덕션 등)

여러 환경 (QA, 스테이징, 프로덕션, 개발 등)을 관리하기위한 K8S의 모범 사례로 간주되는 것은 무엇입니까?

예를 들어, 팀이 프런트 엔드 애플리케이션과 함께 몇 가지 API를 배포해야하는 제품을 작업하고 있다고 가정 해 보겠습니다. 일반적으로 최소 2 개의 환경이 필요합니다.

• 스테이징 : 클라이언트에 릴리스하기 전에 반복 / 테스트 및 검증
• 프로덕션 : 클라이언트가 액세스 할 수있는 환경입니다. 안정적이고 잘 테스트 된 기능을 포함해야합니다.

그렇다면 팀이 Kubernetes를 사용한다고 가정하면 이러한 환경을 호스팅하는 좋은 방법은 무엇일까요? 지금까지 두 가지 옵션을 고려했습니다.

1. 각 환경에 K8s 클러스터 사용
2. 하나의 K8 클러스터 만 사용하고 서로 다른 네임 스페이스에 보관하십시오.

(1) 생산 환경을 위험에 빠뜨릴 수있는 잠재적 인 인간 실수 및 기계 고장의 위험을 최소화하기 때문에 가장 안전한 옵션으로 보입니다. 그러나 이것은 더 많은 마스터 머신의 비용과 더 많은 인프라 관리 비용을 동반합니다.

(2) 단일 클러스터가 하나이기 때문에 인프라 및 배포 관리를 단순화하는 것처럼 보이지만 다음과 같은 몇 가지 질문이 제기됩니다.

• 사람의 실수가 프로덕션 환경에 영향을 미칠 수 있는지 어떻게 확인합니까?
• 스테이징 환경의 높은로드로 인해 프로덕션 환경의 성능이 저하되지 않도록하려면 어떻게해야합니까?

다른 문제가있을 수 있으므로 StackOverflow의 K8 커뮤니티에 연락하여 사람들이 이러한 종류의 문제를 처리하는 방법을 더 잘 이해하고 있습니다.

다중 클러스터 고려 사항

Vadim Eisenberg ( IBM / Istio ) 의이 블로그 게시물을 살펴보십시오 . 체크리스트 : 여러 Kubernetes 클러스터 사용의 장단점 및 이들 사이에 워크로드를 분산하는 방법 .

몇 가지 장단점을 강조하고 싶습니다.

클러스터가 여러 개있는 이유

• 프로덕션 / 개발 / 테스트 분리 : 특히 Kubernetes의 새 버전, 서비스 메시, 기타 클러스터 소프트웨어 테스트 용
• 규정 준수 : 일부 규정에 따라 일부 애플리케이션은 별도의 클러스터 / 별도의 VPN에서 실행해야합니다.
• 보안을위한 더 나은 격리
• 클라우드 / 온 프레미스 : 온 프레미스 서비스간에로드 분할

단일 클러스터가있는 이유

• 설정, 유지 관리 및 관리 오버 헤드 감소
• 활용도 향상
• 비용 절감

너무 비싸지 않은 환경과 평균적인 유지 관리를 고려하면서도 프로덕션 애플리케이션에 대한 보안 격리를 보장하는 경우 다음을 권장합니다.

• DEV 및 STAGING을위한 클러스터 1 개 (네임 스페이스로 구분되며 Calico 와 같이 네트워크 정책을 사용하여 격리 될 수도 있음 )
• PROD 용 클러스터 1 개

환경 패리티

개발, 스테이징 및 프로덕션을 최대한 유사하게 유지 하는 것이 좋습니다 .

지원 서비스 간의 차이는 작은 비 호환성이 발생하여 개발 또는 스테이징에서 작동하고 테스트를 통과 한 코드가 프로덕션에서 실패하게됩니다. 이러한 유형의 오류는 지속적인 배포를 방해하는 마찰을 일으 킵니다.

강력한 CI / CD 도구와 helm을 결합합니다 . helm 값 의 유연성을 사용하여 환경에 따라 다른 구성을 재정 의하여 기본 구성을 설정할 수 있습니다 .

AutoDevops가 포함 된 GitLab CI / CD 는 Kubernetes와의 강력한 통합을 제공하므로 이미 Helm 지원 을 통해 여러 Kubernetes 클러스터를 관리 할 수 ​​있습니다.

여러 클러스터 관리 ( kubectl상호 작용)

여러 Kubernetes 클러스터로 작업 할 때 컨텍스트를 엉망 kubectl으로 만들고 잘못된 클러스터에서 실행하기 쉽습니다 . 그 외에도 Kubernetes에는 클라이언트 ( )와 서버 (kubernetes 마스터) 간의 버전 불일치에 대한 제한 이 kubectl있으므로 올바른 컨텍스트에서 명령을 실행한다고해서 올바른 클라이언트 버전을 실행하는 것은 아닙니다.

이를 극복하려면 :

• asdf여러 kubectl버전 관리에 사용
• KUBECONFIG여러 kubeconfig파일 간에 변경 하도록 env var 설정
• kube-ps1현재 컨텍스트 / 네임 스페이스를 추적하는 데 사용 합니다.
• 및를 사용 kubectx하여kubens 클러스터 / 네임 스페이스간에 빠르게 변경
• 별칭을 사용하여 모두 함께 결합

이 작업을 수행하는 방법을 보여주는 기사가 있습니다. 여러 Kubernetes 클러스터와 함께 다른 kubectl 버전 사용

또한 다음 읽기를 권장합니다.

• Ahmet Alp Balkan ( Google 엔지니어 ) 의 KUBECONFIG 파일 마스터 링
• Zalando 가 Henning Jacobs ( Zalando Tech )의 140 개 이상의 Kubernetes 클러스터 를 관리하는 방법

개발 및 도커 이미지 생성에 별도의 클러스터를 사용하여 스테이징 / 프로덕션 클러스터를 보안 현명하게 잠글 수 있습니다. 별도의 클러스터 사용 여부 staging + production는 위험 / 비용에 따라 결정해야합니다. 확실히 별도로 유지하면 staging영향을 피하는 데 도움이됩니다.production .

또한 GitOps를 사용하여 환경간에 앱 버전을 홍보하는 것이 좋습니다.

인적 오류를 최소화하기 위해 CI / CD 및 프로모션을 위해 가능한 한 자동화를 고려하는 것이 좋습니다.

다음 은 Jenkins X가 대부분의 kubernetes 클러스터를 지원하지만 GKE에서 라이브로 수행 된 풀 요청에 대한 환경과 미리보기 환경 간의 승격을 위해 GitOps 를 사용하여 Kubernetes의 여러 환경에서 CI / CD를 자동화하는 방법에 대한 데모입니다.

각 시나리오에서 테스트하려는 항목에 따라 다릅니다. 일반적으로 불필요한 부작용 (성능 영향 등)을 피하기 위해 프로덕션 클러스터에서 테스트 시나리오를 실행하지 않으려 고합니다.

프로덕션 시스템 을 정확히 모방 하는 스테이징 시스템으로 테스트하려는 경우 전체 클러스터의 정확한 복제본을 실행하고 테스트를 완료하고 배포를 프로덕션으로 이동 한 후 종료하는 것이 좋습니다.

목적이 애플리케이션 테스트 를 허용하는 스테이징 시스템 테스트 인 경우 배포를 더 작은 스테이징 클러스터를 영구적으로 실행하고 지속적인 테스트에 필요한 배포 (배포의 축소 버전 포함)를 업데이트합니다.

다른 클러스터를 제어하기 위해 클러스터의 일부가 아니지만 클러스터를 시작 및 종료하고 배포 작업을 수행하고 테스트를 시작하는 데 사용되는 별도의 ci / cd 시스템을 선호합니다. 이렇게하면 설정 및 종료가 가능합니다. 자동화 된 테스트 시나리오의 일부로 클러스터.

스테이징 클러스터에서 프로덕션 클러스터 앱을 유지하면 프로덕션 서비스에 영향을 미치는 잠재적 오류의 위험이 줄어 듭니다. 그러나 최소한 다음이 필요하기 때문에 더 많은 인프라 / 구성 관리 비용이 발생합니다.

• 프로덕션 클러스터 용 마스터 3 개 이상 및 스테이징 클러스터 용 마스터 1 개 이상
• CI / CD 시스템에 추가 할 Kubectl 구성 파일 2 개

또한 하나 이상의 환경이있을 수 있음을 잊지 마십시오. 예를 들어 저는 최소한 3 개의 환경이있는 회사에서 일했습니다.

• QA : 여기에서 매일 배포하고 클라이언트에게 배포하기 전에 내부 QA를 수행했습니다.)
• 클라이언트 QA : 클라이언트가 프로덕션으로 릴리스하기 전에 환경을 검증 할 수 있도록 프로덕션에 배포하기 전에 배포했습니다.)
• 프로덕션 : 프로덕션 서비스가 배포되는 곳입니다.

임시 / 온 디맨드 클러스터가 타당하다고 생각하지만 특정 사용 사례 (로드 / 성능 테스트 또는 매우«큰»통합 / 엔드 투 엔드 테스트)에만 적용되지만보다 지속적 / 고정적인 환경에서는 감소 될 수있는 오버 헤드가 있습니다. 단일 클러스터 내에서 실행합니다.

제가 설명한 것과 같은 시나리오에 어떤 패턴이 사용되는지 알아보기 위해 k8s 커뮤니티에 연락하고 싶었습니다.

규정 준수 또는 기타 요구 사항에서 달리 지시하지 않는 한 모든 환경에 단일 클러스터를 선호합니다. 이 접근 방식을 사용할 경우주의 사항은 다음과 같습니다.

• 레이블을 사용하여 환경별로 노드를 그룹화해야합니다. 그런 다음 nodeSelectoron 리소스를 사용하여 특정 노드에서 실행 중인지 확인할 수 있습니다. 이렇게하면 환경간에 (과도한) 리소스 소비가 넘칠 가능성이 줄어 듭니다.

• 네임 스페이스를 서브넷으로 취급하고 기본적으로 모든 송신 / 수신 트래픽을 금지합니다. https://kubernetes.io/docs/concepts/services-networking/network-policies/를 참조 하십시오 .

• 서비스 계정 관리 전략이 있습니다. ClusterRoleBindings클러스터가 둘 이상의 환경을 호스트하는 경우 다른 것을 의미합니다.

• Helm과 같은 도구를 사용할 때는 면밀히 조사하십시오. 일부 차트는 클러스터 전체 권한을 가진 서비스 계정을 노골적으로 설치하지만 서비스 계정에 대한 권한은 해당 환경으로 제한되어야합니다.

여러 클러스터를 사용하는 것은 프로덕션과 "비 프로덕션"간의 강력한 분리를 강제하기 위해 목록에서 표준입니다.

그런 의미에서 GitLab 13.2 (2020 년 7 월) 에는 이제 다음이 포함됩니다.

Core의 다중 Kubernetes 클러스터 배포

GitLab을 사용하여 GitLab으로 여러 Kubernetes 클러스터를 배포하려면 이전에 Premium 라이선스가 필요했습니다.
우리 커뮤니티는 이야기를 듣고 귀를 기울였습니다. 여러 클러스터에 배포하는 것은 개별 기여자에게도 유용합니다.
피드백에 따라 GitLab 13.2부터 Core의 여러 그룹 및 프로젝트 클러스터에 배포 할 수 있습니다.

문서 및 문제 참조 /

단일 클러스터를 실행하면 오버 헤드와 모니터링이 줄어들 기 때문에 합리적이라고 생각합니다. 그러나 네트워크 정책, 액세스 제어를 배치해야합니다.

네트워크 정책-제품 / 스테이징 저장소와 상호 작용하는 dev / qa 환경 워크로드를 금지합니다.

액세스 제어-ClusterRoles, Roles 등을 사용하여 다른 환경 리소스에 액세스 할 수있는 사람.