Environ 소개

Envion은 클러스터 및 기타 리소스를 논리적으로 구성하기 위한 Google Cloud 개념으로, 멀티 클러스터 기능을 사용 및 관리하고 시스템 전체에 일관된 정책을 적용할 수 있습니다. Envion은 Anthos에서 엔터프라이즈 멀티 클러스터 기능 작동 방식의 중요한 부분을 차지합니다. 또한 일부 Google Kubernetes Engine(GKE) 기능에서도 사용됩니다.

이 가이드에서는 Envion의 의미, Envion이 구성요소에서 사용되는 위치, Envion 수준 기능을 활용하도록 시스템을 설정하는 방법 등 Envion에 대해 소개합니다. 또한 Envion이 클러스터 및 시스템 관리를 간소화하는 데 어떻게 도움이 되는지를 보여주는 몇 가지 예시와 Envion으로 멀티 클러스터 시스템을 빌드하고 운영할 때 따라야 하는 권장사항 도 제공합니다.

이 가이드는 시스템 설계자, 플랫폼 운영자, 서비스 운영자 등 여러 클러스터 및 관련 인프라를 활용하려는 기술 리더를 대상으로 작성되었습니다. 이러한 개념은 조직에서 Google Cloud, 여러 클라우드 제공업체, 온프레미스에서 여러 클러스터를 실행할 때 유용합니다.

클러스터 등의 기본 Kubernetes 개념을 잘 알고 있어야 합니다. 이러한 개념을 잘 모른다면 Kubernetes 기본사항, GKE 문서, Anthos Service Mesh용 애플리케이션 준비를 참조하세요.

Environ을 사용하는 구성요소와 Anthos에 대해 더 알아보려면 Anthos 기술 개요Anthos 살펴보기 가이드를 참조하세요. 하지만 Anthos에 대해 잘 몰라도 이 가이드를 진행할 수 있습니다.

소개

일반적으로 조직은 컨테이너, 컨테이너 조정, 서비스 메시와 같은 클라우드 기반 기술을 사용하므로 단일 클러스터 실행으로는 더 이상 충분하지 않을 수 있습니다. 조직에서 기술 및 비즈니스 목표를 달성하기 위해 여러 클러스터를 배포하는 이유는 프로덕션 환경과 비프로덕션 환경을 분리하거나 계층, 언어, 팀별로 서비스를 분리하는 등 다양합니다. 멀티 클러스터 사용 사례에서 멀티 클러스터 접근 방식과 관련된 이점과 단점에 대해 자세히 알아볼 수 있습니다.

클러스터 수가 증가함에 따라 이러한 클러스터와 클러스터 내 리소스에 대한 관리 및 거버넌스를 제공하는 것이 점점 더 어려워지고 있습니다. 이 시점에서 조직은 필요한 제어 수준을 얻기 위해 커스텀 도구와 운영 정책을 빌드하는 만드는 경우가 많습니다.

Google Cloud는 관리자가 여러 클러스터를 관리하는 데 도움이 되는 Envron 개념을 제공합니다. Environ에서는 클러스터를 논리적으로 그룹화하고 정규화할 수 있는 방법을 제공되므로 인프라를 쉽게 관리할 수 있습니다. Envion은 Anthos와 GKE 모두의 컨텍스트에서 사용할 수 있습니다. 이 문서 뒷부분의 Environ이 사용 설정된 구성요소 섹션에서 Environ을 활용할 수 있는 Anthos 및 GKE 구성요소 목록을 확인할 수 있습니다.

Environ을 채택하면 조직에서는 개별 클러스터에서 전체 클러스터 그룹으로 관리 수준을 높일 수 있습니다. 또한 Environ에 필요한 정규화는 팀이 Google에서 사용되는 것과 유사한 권장사항을 채택하는 데 도움이 될 수 있습니다. 조직 리소스가 Google Cloud 리소스 계층 구조의 루트 노드이고 그 아래에 그룹화된 리소스에 대한 정책 및 제어에 사용되는 것처럼, Environ은 여러 클러스터를 관리하기 위한 루트를 형성합니다.

용어

Environ에 대해 설명할 때 사용하는 중요 용어는 다음과 같습니다.

Environ 인식 리소스

Environ 인식 리소스는 논리적으로 Environ으로 그룹화하여 관리할 수 있는 Google Cloud 프로젝트 리소스입니다. 현재 Kubernetes 클러스터만 Environ 구성원일 수 있습니다. 하지만 가상 머신(VM) 인스턴스와 다른 리소스가 향후 플랫폼 반복에서 Environ을 조인할 수 있습니다. Google Cloud는 Environ 구성원로 리소스를 등록하는 Connect 서비스를 제공합니다.

Environ 호스트 프로젝트

다른 많은 Google Cloud 리소스와 마찬가지로 Environ 구현은 Environ 호스트 프로젝트라고 하는 Google Cloud 프로젝트에 기반합니다. 지정된 Cloud 프로젝트에는 단일 Environ만 연결될 수 있습니다(또는 Environ 없음). 이 제한사항은 Cloud 프로젝트를 사용하여 함께 적용되지 않거나 함께 소비되지 않는 리소스 간에 더욱 강력한 격리 조치를 적용합니다.

Environ이 사용 설정된 구성요소

다음 Anthos 및 GKE 구성요소는 모두 네임스페이스 및 ID 동일성과 같은 Environ 개념을 활용하여 클러스터 및 서비스로 작업할 수 있는 더욱 단순화된 방법을 제공합니다. 각 구성요소와 함께 Environ 사용에 대한 현재의 요구사항 또는 제한사항은 구성요소 요구사항을 참조하세요.

  • 워크로드 아이덴티티 풀(Anthos 및 GKE 클러스터)
    Environ은 공통 워크로드 아이덴티티 풀을 제공하여 서비스 메시 내에서 그리고 외부 서비스에 대해 워크로드를 균일하게 인증하고 승인할 수 있습니다.

  • Anthos Service Mesh(Anthos)
    Anthos Service Mesh는 Google Cloud 또는 온프레미스에서 안정적인 서비스 메시를 모니터링하고 관리할 수 있는 도구 모음입니다. 동일한 Environ의 일부인 리소스(예: 클러스터 및 VM)에서 서비스 메시를 형성할 수 있습니다.

  • Anthos Config Management(Anthos) 및 Config Sync(GKE)
    Anthos Config Management를 사용하면 네임스페이스, 라벨, 주석 등의 핵심 Kubernetes 개념을 활용하여 중앙 Git 저장소에 저장된 시스템의 선언적 정책 및 구성 변경사항을 배포하고 모니터링할 수 있습니다. Anthos Config Management(및 Anthos 클러스터가 아닌 클러스터의 형제 제품 구성 동기화)를 통해 정책 및 구성이 Environ 간에 정의되지만 각 구성원 리소스에서 로컬로 적용 및 시행됩니다.

  • 멀티 클러스터 인그레스(Anthos)
    멀티 클러스터 인그레스는 Environ을 사용하여 트래픽 부하가 분산될 수 있는 클러스터 및 서비스 엔드포인트 집합을 정의하여 지연 시간이 짧은 고가용성 서비스를 제공합니다.

인프라 그룹화

Environ의 첫 번째 중요한 개념은 그룹화 개념입니다. 즉, Environ의 일부가 될 관련 Environ 인식 리소스를 선택하는 것입니다. 그룹화할 항목을 결정하려면 다음 질문에 답해야 합니다.

  • 리소스가 서로 관련되어 있나요?
    • 서비스 간 통신이 많은 리소스는 Environ에서 함께 관리할 경우 가장 효과적입니다.
    • 동일한 배포 환경(예: 프로덕션 환경)의 리소스는 Environ에서 함께 관리해야 합니다.
  • 리소스를 누가 관리하나요?
    • Environ의 무결성을 보장하려면 리소스를 통합(또는 최소한 상호 신뢰) 제어하는 것이 중요합니다.

이러한 점을 설명하기 위해 여러 비즈니스 계열(LOB)이 있는 조직을 고려해 보세요. 이 경우 서비스는 LOB 경계 간에 통신하는 경우가 거의 없고, 다른 LOB의 서비스는 관리 방식이 다르며(예: 업그레이드 주기는 LOB마다 다름), LOB마다 관리자가 다를 수 있습니다. 이 경우 LOB당 Environ을 갖는 것이 더 나을 수 있습니다. 또한 각 LOB는 프로덕션 서비스와 비프로덕션 서비스를 구분하기 위해 여러 Environ을 도입할 가능성이 높습니다.

다음 섹션에서 다른 Environ 개념을 살펴보면 특정 조직의 요구를 고려할 때 여러 Environ을 만들어야 하는 다른 이유가 있을 수 있습니다.

동일성

Environ에서 중요한 개념은 동일성 개념입니다. 즉, 서로 다른 컨텍스트에서 이름이 동일한 클러스터와 같은 일부 Kubernetes 객체는 동일한 것으로 취급됩니다. 이 정규화를 수행하여 Environ 리소스를 보다 다루기 쉽게 관리할 수 있습니다. 네임스페이스, 서비스, ID를 설정하는 방법에 대한 강력한 지침을 제공합니다. 하지만 대부분의 조직이 이미 자체적으로 구현하고 있는 것을 따릅니다.

네임스페이스 동일성

Environ 동일성의 기본 예시는 네임스페이스 동일성입니다. 여러 클러스터에 이름이 동일한 네임스페이스는 여러 구성요소에서 동일한 것으로 간주됩니다. 이 속성에 대해 고려할 또 다른 방법은 네임스페이스의 인스턴스화가 Environ 리소스의 하위 집합에만 있는 경우에도 네임스페이스가 전체 Environ에서 논리적으로 정의됩니다.

다음 backend 네임스페이스 예시를 살펴보세요. 네임스페이스는 클러스터 A와 B에서만 인스턴스화되지만 클러스터 C에 암시적으로 예약되어 있습니다. 필요한 경우 backend 서비스를 클러스터 C에 예약할 수도 있습니다. 즉, 네임스페이스는 클러스터별로 할당되는 것이 아니라 전체 Environ에 할당됩니다. 따라서 네임스페이스 동일성을 위해 전체 Environ에서 일관된 네임스페이스 소유권이 필요합니다.

Environ의 네임스페이스 동일성을 보여주는 다이어그램
Environ의 네임스페이스 동일성

서비스 동일성

Anthos Service Mesh 및 멀티 클러스터 인그레스는 네임스페이스 내에서 서비스 동일성 개념을 사용합니다. 네임스페이스 동일성과 마찬가지로 네임스페이스와 서비스 이름이 동일한 서비스는 동일한 서비스로 간주됩니다.

Anthos Service Mesh의 경우 서비스 엔드포인트를 메시 간에 병합할 수 있습니다. 멀티 클러스터 인그레스에서는 MultiClusterService(MCS) 리소스를 통해 엔드포인트가 더 명시적으로 병합됩니다. 하지만 이름 지정과 관련하여 유사한 권장사항을 따르는 것이 좋습니다. 이로 인해 동일한 네임스페이스 내에서 동일한 이름의 서비스가 실제로 같은 서비스인지 확인하는 것이 중요합니다.

다음 예시에서 인터넷 트래픽은 클러스터 B와 C 모두에 있는 frontend 네임스페이스에서 동일한 이름의 서비스에 부하 분산됩니다. 마찬가지로 frontend 서비스는 Environ 내에서 서비스 메시 속성을 사용하면 클러스터 A와 C에 있는 auth 네임스페이스에서 동일한 이름의 서비스에 연결할 수 있습니다.

Environ의 서비스 동일성을 보여주는 다이어그램
Environ의 서비스 동일성

외부 리소스에 액세스할 때 ID 동일성

Environ 내에서 서비스는 Google Cloud 서비스, 객체 저장소 등의 외부 리소스에 액세스하기 위해 이그레스할 때 공통 ID를 활용할 수 있습니다. 이 공통 ID를 사용하면 Environ 내에서 서비스가 클러스터 단위가 아니라 한번만 외부 리소스에 액세스할 수 있습니다.

이 점을 더 자세히 설명하기 위해 다음 예시를 살펴보세요. 클러스터 A, B, C는 Environ 내에서 공통 ID로 등록됩니다. backend 네임스페이스의 서비스가 Google Cloud 리소스에 액세스하면 해당 ID는 back이라는 일반적인 Google Cloud 서비스 계정에 매핑됩니다. Google Cloud 서비스 계정(back)은 Cloud Storage부터 Cloud SQL까지 모든 관리형 서비스에 대해 승인을 받을 수 있습니다. 클러스터와 같은 새로운 Environ 리소스가 backend 네임스페이스에 추가되면 워크로드 아이덴티티의 동일성 속성을 자동으로 상속합니다.

ID 동일성으로 인해 Environ의 모든 리소스를 신뢰할 수 있고 잘 관리하는 것이 중요합니다. 이전 예시를 다시 보면, 클러스터 C를 별도의 신뢰할 수 없는 팀에서 소유한 경우 backend 네임스페이스를 만들고 클러스터 A 또는 B의 backend처럼 관리형 서비스에 액세스할 수 있습니다.

Environ 외부의 리소스에 액세스하는 ID 동일성을 보여주는 다이어그램
Environ 외부의 리소스에 액세스하는 ID 동일성

Environ 내 ID 동일성

Environ 내에서 ID는 앞서 언급한 외부 ID 동일성과 유사하게 사용됩니다. Environ 서비스는 외부 서비스에 대해 한 번 승인되는 것처럼 내부적으로도 승인될 수 있습니다.

다음 예시에서 frontendbackend에 대한 액세스 권한을 부여했습니다. Environ을 사용하면 클러스터 B와 C의 frontend가 클러스터 A와 B의 backend에 액세스할 수 있도록 지정할 필요가 없습니다. 대신 Environ의 frontend가 Environ의 backend에 액세스할 수 있도록 지정합니다. 이 속성은 승인을 단순화할 뿐만 아니라 리소스 경계의 유연성을 높여줍니다. 이제 승인 방식에 영향을 주지 않으면서 워크로드를 클러스터 간에 쉽게 이동할 수 있습니다. 워크로드 아이덴티티 동일성과 마찬가지로 서비스 간 통신의 무결성을 보장하려면 Environ 리소스에 대한 거버넌스가 중요합니다.

환경 내부의 ID 동일성을 보여주는 다이어그램
환경 내부의 ID 동일성

독점성

Environ-인식 리소스는 특정 시점에 단일 Environ의 구성원만 될 수 있으며 이는 Google Cloud 도구 및 구성요소에 의해 적용되는 제한사항입니다. 이 제한사항으로 인해 클러스터를 관리하는 정보 소스가 하나만 있습니다. 독점성 없이는 가장 단순한 구성 요소도 사용하기가 복잡해지므로 조직은 여러 Environ의 여러 구성요소가 상호작용하는 방식을 추론하고 구성해야 합니다.

높은 신뢰도

서비스 동일성, 워크로드 아이덴티티 동일성, 메시 ID 동일성은 Environ 구성원 간의 높은 신뢰도 원칙에 따라 빌드됩니다. 이 신뢰도를 사용하면 이러한 리소스를 리소스 단위(즉, Kubernetes 리소스의 클러스터 단위)로 관리하는 대신 Environ으로 관리 수준을 높일 수 있고 궁극적으로 클러스터 경계가 덜 중요합니다.

다시 말해 Environ 내에서 클러스터는 영향 범위, 가용성(제어 영역과 기본 인프라 모두), 트래픽 많은 이웃 등으로부터 보호합니다. 그러나 Environ에 있는 모든 구성원의 관리자가 Environ의 다른 구성원에서 서비스 운영에 영향을 미칠 수 있으므로 정책 및 거버넌스에 대한 강력한 격리 경계가 아닙니다.

이러한 이유로 Environ 관리자는 격리 상태를 유지하기 위해 신뢰하지 않는 리소스를 자체 Environ에 배치하는 것이 좋습니다. 그런 다음 필요에 따라 개별 서비스를 Environ 경계에서 승인할 수 있습니다.

다음 단계

이러한 개념을 자체 시스템에 적용할 준비가 되셨나요? Environ 요구사항 및 권장사항을 참조하세요.