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

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

---

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

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

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

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

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

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

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

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

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

---

개발 및 도커 이미지 생성에 별도의 클러스터를 사용하여 스테이징 / 프로덕션 클러스터를 보안 현명하게 잠글 수 있습니다. 별도의 클러스터를 사용 여부에 대한은 staging + production확실히 그들에게 별도의 의지 도움말 피할 유지 - 위험 / 비용을 기반으로 결정하는 당신에게 달려 staging영향을 미치는를 production.

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

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

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

---

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

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

응용 프로그램 배포를 테스트 할 수있는 스테이징 시스템을 테스트하는 것이 목적이라면 더 작은 스테이징 클러스터를 영구적으로 실행하고 지속적인 테스트에 필요한 배포를 업데이트합니다 (배포의 축소 버전도 포함).

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

---

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

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

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

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

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

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

---

다중 클러스터 고려 사항

이 블로그 게시물을 살펴보십시오. 체크리스트 : 여러 Kubernetes 클러스터 사용의 장단점, 클러스터간에 워크로드를 분산하는 방법 .

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

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

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

단일 클러스터가있는 이유

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

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

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

환경 패리티

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

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

Combine a powerful CI/CD tool with helm. You can use the flexibility of helm values to set default configurations, just overriding the configs that differ from an environment to another.

GitLab CI/CD with AutoDevops has a powerful integration with Kubernetes, which allows you to manage multiple Kubernetes clusters already with helm support.

Managing multiple clusters (kubectl interactions)

When you are working with multiple Kubernetes clusters, it’s easy to mess up with contexts and run kubectl in the wrong cluster. Beyond that, Kubernetes has restrictions for versioning mismatch between the client (kubectl) and server (kubernetes master), so running commands in the right context does not mean running the right client version.

To overcome this:

• Use asdf to manage multiple kubectl versions
• Set the KUBECONFIG env var to change between multiple kubeconfig files
• Use kube-ps1 to keep track of your current context/namespace
• Use kubectx and kubens to change fast between clusters/namespaces
• Use aliases to combine them all together

Take a look at this article, it explains how to accomplish this: Using different kubectl versions with multiple Kubernetes clusters

I also recommend this read: Mastering the KUBECONFIG file

---

Unless compliance or other requirements dictate otherwise, I favor a single cluster for all environments. With this approach, attention points are:

• Make sure you also group nodes per environment using labels. You can then use the nodeSelector on resources to ensure that they are running on specific nodes. This will reduce the chances of (excess) resource consumption spilling over between environments.

• Treat your namespaces as subnets and forbid all egress/ingress traffic by default. See https://kubernetes.io/docs/concepts/services-networking/network-policies/.

• Have a strategy for managing service accounts. ClusterRoleBindings imply something different if a clusters hosts more than one environment.

• Use scrutiny when using tools like Helm. Some charts blatantly install service accounts with cluster-wide permissions, but permissions to service accounts should be limited to the environment they are in.

---

I think running a single cluster make sense because it reduces overhead, monitoring. But, you have to make sure to place network policies, access control in place.

Network policy - to prohibit dev/qa environment workload to interact with prod/staging stores.

Access control - who have access on different environment resources using ClusterRoles, Roles etc..

참고URL : https://stackoverflow.com/questions/43212836/multiple-environments-staging-qa-production-etc-with-kubernetes