Kubernetes를 사용한 이기종 배포 패턴

이 문서에서는 Kubernetes를 사용하여 프로덕션 수준의 이기종 배포를 만들기 위한 일반적인 패턴을 설명합니다. 이 문서에서는 세 가지 사용 사례를 살펴보고, 이를 위한 배포를 만들기 위해 사용할 수 있는 아키텍처 세부정보를 설명합니다. 아키텍처 설명에는 일반적인 Kubernetes 설명과 GKE(Google Kubernetes Engine )에 대한 구체적인 설명이 포함됩니다.

이기종 배포

이기종 배포에서는 일반적으로 특정한 기술적 또는 운영적 요구를 해결하기 위해 2개 이상의 고유한 인프라 환경 또는 지역을 연결합니다. 이기종 배포는 배포 특성에 따라 '하이브리드', '다중 클라우드' 또는 '공용-사설'이라고 부릅니다. 이 문서에서 이기종 배포에는 단일 클라우드 환경, 다중 공용 클라우드 환경(다중 클라우드), 온프레미스와 공용 클라우드 환경의 조합(하이브리드 또는 공용-사설)에 있는 지역들에 걸친 배포가 포함됩니다.

단일 환경 또는 지역으로 제한된 배포에서는 다양한 비즈니스 및 기술적 과제가 발생할 수 있습니다.

  • 최대치로 소모된 리소스: 모든 단일 환경, 특히 온프레미스 환경에서는 프로덕션 요구를 충족시킬 수 있는 컴퓨팅, 네트워킹, 저장소 리소스가 없을 수 있습니다.
  • 제한된 지리적 범위: 단일 환경에서의 배포를 위해서는 지리적으로 서로 멀리 떨어진 사용자들이 하나의 배포에 액세스해야 합니다. 이러한 사용자의 트래픽은 특정 위치까지 전 세계를 돌아서 이동합니다.
  • 제한된 가용성: 웹 규모의 트래픽 패턴에서는 앱의 내결함성 및 탄력성이 요구됩니다.
  • 공급업체 잠김: 공급업체 수준의 플랫폼 및 인프라 추상화로 인해 앱 이식이 방해될 수 있습니다.
  • 유연하지 않은 리소스: 특정 컴퓨팅, 저장소 또는 네트워킹 오퍼링 집합으로 리소스가 제한될 수 있습니다.

이기종 배포는 이러한 문제를 해결하는 데 도움이 될 수 있지만, 프로그래매틱 방식 및 결정적 방식의 프로세스와 절차를 사용해서 아키텍처를 구성해야 합니다. 일회성 또는 임시 배포 절차는 배포 또는 프로세스의 취약성을 높이고 내결함성을 저하시킬 수 있습니다. 임시 프로세스는 데이터 손실 또는 트래픽 누락을 일으킬 수 있습니다. 올바른 배포 프로세스는 반복 가능해야 하며, 프로비저닝, 구성, 유지 관리에 대해 입증된 방식을 사용해야 합니다.

이기종 배포를 위한 일반적인 시나리오는 다중 클라우드 배포, 온프레미스 데이터 프론팅, CI/CD(지속적 통합/지속적 배포) 프로세스입니다.

다음 섹션에서는 Kubernetes 및 다른 인프라 리소스를 사용한 잘 구성된 접근 방법과 함께 이기종 배포를 위한 몇 가지 일반적인 사용 사례를 설명합니다.

다중 클라우드

모든 배포가 비교적 비슷한 형태를 갖는 다중 클라우드 배포는 Kubernetes에서 사용되는 가장 일반적인 이기종 배포 패턴에 속합니다.

다중 클라우드 배포의 한 가지 용도는 트래픽 방향 선택과 관련됩니다. 가장 간단한 배포에서는 인바운드 트래픽 중 일정 비율을 특정 배포로 전송하도록 선택할 수 있습니다. 온프레미스 및 공용 클라우드 인프라에서 빌드된 배포에서는 장기 이전을 돕거나 제한적인 온프레미스 리소스를 해결하기 위해 클라우드 인프라로 더 많은 트래픽을 전송할 수 있습니다.

다중 클라우드 배포의 또 다른 일반적인 용도는 단일 환경의 결함을 견딜 수 있는 가용성이 뛰어난 배포를 구성하는 것입니다. 이러한 시나리오에서는 원하는 각 환경에 동일한 Kubernetes 배포를 조정할 수 있습니다. 각 배포는 단일 환경이 실패할 때 모든 트래픽 요구를 충족시킬 수 있도록 확장 가능해야 합니다.

마지막으로 다중 클라우드 배포를 사용하면 사용자에게 물리적으로 가까이 있는 배포를 만들 수 있습니다. 사용자에게 가능한 한 가깝게 배포를 배치하면 요청 및 응답 지연 시간을 최소화할 수 있습니다.

트래픽 방향 지정

강력한 다중 클라우드 배포는 DNS 트래픽 관리 서비스를 사용해서 개별 배포에 대한 DNS 쿼리를 해결합니다. 일반적인 트래픽 분할 사용 사례를 위해서는 개별 배포 간에 백분율로 트래픽을 분할하도록 DNS 트래픽 관리 메커니즘을 구성할 수 있습니다.

트래픽 분할

가용성이 높은 배포를 위해서는 각 환경의 커스텀 상태 검사를 사용해서 DNS 메커니즘을 구성할 수 있습니다. 환경이 비정상 상태가 되면 정상 상태 업데이트 전송을 중지하고, DNS 메커니즘이 아직 정상 상태인 배포로 트래픽을 전환할 수 있습니다.

사용자에 대한 지연 시간이 중요한 경우, DNS 메커니즘은 인바운드 요청의 IP 주소를 사용해서 대략적인 위치를 확인한 후 해당 지리적 지역에 가장 가까운 배포로 트래픽 방향을 지정할 수 있습니다. NS1, Dyn, Akamai 등과 같은 DNS 인프라 서비스 공급업체를 사용해서 여러 배포 간의 트래픽 방향을 지정할 수 있습니다.

요청 처리

DNS가 트래픽 방향을 특정 배포로 지정하면, 부하 분산기가 들어오는 요청을 수신하고 이를 Kubernetes 클러스터로 전달합니다. Kubernetes는 들어오는 트래픽에 대해 포드를 노출하기 위해 서비스Ingress라는 두 가지 방법을 제공합니다.

포드가 Kubernetes 클러스터에 배포된 경우, 다른 앱 또는 클러스터 내부 또는 외부에 있는 시스템에서 쉽게 액세스할 수 없습니다. 포드에 액세스할 수 있게 하려면 먼저 서비스를 만들어야 합니다. 기본적으로 서비스는 클러스터 내부의 연결을 자동으로 수락하지만, 클러스터 외부의 연결도 수락하도록 구성할 수 있습니다.

외부 요청을 수락하도록 서비스를 구성할 때는 서비스 유형을 NodePort 또는 LoadBalancer로 구성합니다.

서비스 유형을 NodePort로 설정하면 Kubernetes 클러스터의 모든 노드에서 각 서비스에 대한 고유 포트가 노출됩니다. 이러한 고유 포트는 각 노드가 연결을 수락하고, 들어오는 요청을 적절한 포드로 프록시 부하 분산할 수 있게 해줍니다.

LoadBalancer 서비스 유형에는 NodePort가 포함됩니다. 각 노드에서 포트 구성을 제공하는 것 외에도, 유형을 LoadBalancer로 설정하면 외부 부하 분산기를 자동으로 프로비저닝하고 트래픽을 클러스터 및 후속 포드로 전달하도록 구성합니다.

Kubernetes의 서비스는 계층 4 구성입니다. 즉, IP 주소 및 포트 번호만 사용해서 액세스를 지원할 수 있습니다. HTTP(S)(계층 7) 부하 분산 메커니즘은 Ingress는 인바운드 연결이 백엔드 Kubernetes 클러스터 서비스에 연결하도록 허용하는 규칙의 모음입니다. 외부에서 연결 가능한 URL, 인바운드 트래픽 부하 분산, SSL 종료 또는 이름 기반 가상 호스팅과 같은 추가 앱 계층 기능을 서비스에 제공하도록 Ingress 메커니즘을 구성할 수 있습니다. HTTP 호스트 헤더 또는 HTTP URL 경로를 사용해서 서비스를 통해 노출되는 포드로 인바운드 트래픽을 전달할 수 있습니다.

포드로 전달되는 트래픽

공유 서비스

다중 클라우드 배포를 실행할 때는 각 배포에서 데이터베이스와 같은 하나 이상의 공유 서비스를 실행해야 할 수 있습니다. 공유 서비스 사이의 통신은 지연 시간이 낮고 안전해야 합니다.

낮은 지연 시간, 높은 대역폭 연결을 위해서는 직접 피어링 또는 제3자에서 관리되는 네트워크 상호 연결을 사용해서 각 배포의 기본 네트워크를 연결할 수 있습니다. GCP는 사용 가능한 네트워크 에지 위치 중 하나에서 Google과의 직접 피어링을 통해 직접 연결을 제공합니다. 직접 피어링을 사용하기 위해서는 많은 기술적 요구 사항이 있습니다. 이러한 요구 사항을 충족시킬 수 없는 경우에는 Cloud Interconnect를 사용할 수 있습니다. Cloud Interconnect 서비스 제공업체를 사용하면 엔터프라이즈급 연결 성능으로 Google 네트워크 에지에 연결할 수 있습니다.

연결이 수행된 다음에는 VPN을 사용해서 각 환경 사이의 링크를 보호해야 합니다. 각 배포에서는 배포 간 트래픽 보안을 위해 VPN 게이트웨이가 필요합니다. GCP에서, Cloud VPN은 IPSec VPN 연결을 사용해서 트래픽을 보호합니다. Cloud VPN은 대역폭을 집계하기 위해 여러 VPN 터널을 지원하고 Cloud Router를 사용해서 정적 또는 동적 라우팅을 지원합니다.

클러스터 관리

다중 클라우드 배포에서는 각 Kubernetes 클러스터를 개별 항목으로 관리하고 제어해야 할 수 있습니다. 이렇게 하려면 각 클러스터에서 포드 및 서비스를 수동으로 만들어야 합니다. 이렇게 하면 각 배포가 일부 앱 및 서비스를 공유하더라도 자신에게만 적합한 앱 및 서비스를 사용할 수 있다는 장점이 있습니다.

예를 들어 배포를 지리적으로 분산시켜야 하지만, 모든 지역에 적합하지는 않은 국가 또는 지역별 서비스도 존재할 수 있습니다.

트래픽 분할이 고르지 않게 분포된 배포의 경우 들어오는 트래픽 및 요청이 적절하게 처리될 수 있도록 클러스터별 기준에 따라 포드 및 서비스를 배포해야 할 수 있습니다.

서비스 검색

다중 클라우드 배포는 여러 앱 및 서비스가 런타임에 서로를 쉽게 찾을 수 있도록 서비스 검색을 사용해야 합니다. 서비스 검색을 사용하면 배포 전 알림이 필요할 수 있는 복잡하거나 취약한 이름 지정 체계 또는 방식을 사용할 필요가 없습니다. 서비스 검색 메커니즘은 소스 및 대상 앱에 투명해야 합니다. 다중 클라우드 배포에서 이러한 메커니즘은 앱 및 서비스가 로컬로 또는 다른 클러스터에서 원격으로 실행되는 서비스를 검색할 수 있게 해야 합니다.

독립형 개별 클러스터로 구성 및 구축된 배포에서 서비스 검색 메커니즘은 데이터 센터를 인식할 수 있어야 합니다. 즉, 들어오는 요청, 로컬 가용성 및 부하 용량을 기준으로 적절한 클러스터로 요청을 전송할 수 있고, 조정된 분산 시스템으로 작동할 수 있어야 합니다. Consul, Linkerd 등과 같은 제3자 시스템은 다중 클라우드 Kubernetes 배포에서 교차 클러스터 및 교차 환경 서비스 검색을 이용할 수 있습니다.

Kubernetes는 Kubernetes 클러스터에서 비공개 DNS 영역의 분석을 지원합니다. 이러한 지원은 다른 클러스터의 정규화된 도메인 이름이 알려져 있고 트래픽을 여기로 쉽게 라우팅할 수 있는 하이브리드 또는 다중 클라우드 시나리오에서 유용합니다. ConfigMap을 사용하여 비공개 '스텁' 도메인에 대한 액세스를 설정할 수 있습니다. Kubernetes 지원을 특정 Kubernetes 클러스터로 요청을 전송하기 위한 독립형 메커니즘으로 사용하거나 Consul과 같은 외부 시스템과 함께 사용하여 비공개 DNS 영역을 분석할 수 있습니다.

아키텍처

다음 다이어그램은 다중 클라우드 배포 아키텍처의 예를 보여줍니다.

다중 클라우드 배포

온프레미스 데이터 프론팅

비공개 또는 온프레미스 배포에서 제공되는 것 이상으로 기능을 확장하기 위해 클라우드 배포를 설계할 수 있습니다. 예를 들어 비공개 데이터 시스템 또는 인프라에 액세스할 수 있는 클라우드 기반 앱을 설계하고 배포할 수 있습니다.

비공개 또는 온프레미스 배포는 가용성, 이식성 또는 리소스 유연성이 제한적일 수 있습니다. 클라우드 기반 배포로 이전하면 이러한 제한을 해결할 수 있지만, 이전 아키텍처, 보안 규정 준수 또는 기타 소프트웨어 요구 사항으로 인해 이것이 불가능할 수 있습니다. 이러한 경우에는 비공개 또는 온프레미스 환경보다 유연성 또는 기능이 뛰어난 클라우드 환경에 앱을 빌드하고 배포할 수 있습니다.

아키텍처

다음 다이어그램은 온프레미스 데이터 인프라를 프론팅하는 클라우드 앱을 보여주는 예제 아키텍처입니다.

온프레미스 데이터 프론팅

네트워킹

클라우드 앱이 온프레미스 데이터 인프라를 프론팅하는 배포의 경우, 전반적인 사용자 앱 응답 시간을 최소화하기 위해 낮은 지연 시간의 보안 연결이 필요합니다. Cloud Interconnect 또는 직접 피어링을 사용하면 지연 시간을 최소화하고 온프레미스 환경과 클라우드 환경 사이에 사용 가능한 대역폭을 최대화할 수 있습니다. 연결이 설정된 후, 각 배포에는 배포 간 트래픽 보안을 위해 VPN 게이트웨이가 있어야 합니다. GCP에서 Cloud VPN은 IPSec VPN 연결을 통해 트래픽을 보호합니다. Cloud VPN은 대역폭 집계를 위해 여러 VPN 터널을 지원하고, Cloud Router를 사용하여 정적 또는 동적 라우팅을 지원합니다. 온프레미스 데이터 인프라를 프론팅할 때 보안은 가장 중요한 요소이기 때문에, 특정 GCP 인스턴스 집합의 트래픽만 허용하도록 경로 및 온프레미스 방화벽을 구성해야 합니다.

클라우드 아키텍처

이러한 하이브리드 배포의 클라우드 부분에서 아키텍처 구성요소에는 적절한 부하 분산기, 앱 호스팅 인프라, VPN 게이트웨이 및 서비스 검색 메커니즘이 포함되어야 합니다. 부하 분산기 선택은 최종 사용자 대면 앱의 요구 사항에 따라 달라집니다. GCP의 배포를 위해 Cloud Load Balancing은 전역에서 사용 가능한 단일 애니캐스트 IP와 함께 HTTP(S), TCP, UDP에 대한 지원을 제공합니다.

이와 같은 하이브리드 시나리오에서는 GCP에서 제공되는 관리되는 Kubernetes 배포인 GKE에서 포드 및 서비스를 배포할 수 있습니다. GKE는 아웃바운드 트래픽을 온프레미스 인프라로 전달합니다. GKE는 Cloud VPN을 사용해서 트래픽을 보호하고, Cloud Router를 사용해서 정적 또는 동적 경로를 구성합니다. 이러한 구성은 GKE 클러스터의 트래픽만 VPN 연결을 통과하도록 보장합니다.

온프레미스 아키텍처

이 배포의 온프레미스 부분에는 클라우드 앱을 지원하는 데이터 인프라가 포함됩니다. 이 특성의 대부분의 배포에서는 데이터 시스템 앞에 CRUD API를 배포하는 것이 여러 이점을 제공합니다.

데이터 시스템에 높은 수준의 보안 또는 규정 준수가 필요한 경우 인바운드 연결 및 쿼리를 감사하고 로깅하는 데에 CRUD API가 유용할 수 있습니다. 데이터 인프라가 이전 시스템에서 실행될 경우 CRUD API는 새로운 앱을 위한 보다 최신의 연결 옵션을 제공하는 데 도움이 될 수 있습니다.

두 경우 모두, CRUD API는 기본 제공되는 데이터베이스 인증 및 승인 메커니즘을 앱에 필요한 메커니즘에서 분리하는 데 도움을 주고, 앱에 필요한 만큼만 CRUD 기능을 제공합니다. 특히, 데이터의 하위 집합만 다운스트림 앱에 노출해야 할 경우, 데이터에 대한 액세스를 관리하는 데 API가 유용할 수 있습니다.

감사 연결 및 쿼리를 통해 API는 또한 기본 데이터의 장기적 이전 전략을 정의하는 데에도 도움이 될 수 있습니다. 데이터의 하위 집합만 필요하고, 엄격한 보안 또는 규정 준수 정책에 포함되지 않을 경우, 데이터를 클라우드 플랫폼으로 이전할 수 있습니다.

위의 아키텍처 다이어그램에서는 온프레미스로 실행되는 Kubernetes에서 호스팅된 CRUD API를 보여줍니다. 온프레미스에서 Kubernetes를 사용하는 것이 기술적인 요구 사항은 아니지만, 몇 가지 이점을 제공합니다. Kubernetes를 클라우드 인프라에서 배포 대상으로 고려하는 팀이 많아질수록 시스템을 사용하고 운영하는 데 따라 늘어나는 전문 기술 개발의 이점을 얻을 수 있습니다.

온프레미스 인프라는 잠재적인 보안 문제를 최소화하기 위해 알려진 소스의 트래픽만 CRUD API에 연결할 수 있도록 VPN 게이트웨이 및 방화벽을 구성해야 합니다.

서비스 검색

하이브리드 배포 시나리오에서는 여러 앱 및 서비스가 런타임에 서로 쉽게 연결할 수 있도록 보장하기 위해 서비스 검색을 사용해야 합니다. 시간이 지남에 따라 온프레미스 CRUD API의 다른 구성요소를 활용하는 추가적인 클라우드 앱을 배포할 수 있습니다. CRUD API는 시간 경과에 따라 작업별 API 또는 온프레미스 데이터 인프라를 추가로 프론팅하기 위한 API와 같은 기능이 추가될 수 있습니다. 이러한 종류의 배포 시나리오에서 클라우드 앱과 온프레미스 CRUD 기능의 출시 주기는 크게 다를 수 있습니다. Consul 또는 Linkerd와 같은 외부 서비스 검색 메커니즘을 사용하면 리소스 및 버전에 대한 느슨한 결합을 제공하여, 각 환경에서 독립적으로 반복되도록 할 수 있습니다.

GKE 또는 Kubernetes에만 클라우드 앱을 배포하려는 경우, 온프레미스 환경에서 비공개 IP 주소로 비공개 DNS 도메인을 분석하도록 내부 Kubernetes DNS 메커니즘 kube-dns를 구성할 수 있습니다. 이러한 구성에서 클라우드 환경에서 실행되는 포드는 표준 DNS 쿼리를 사용하여 온프레미스 환경에서 실행되는 서비스에 쉽게 액세스할 수 있습니다. 자세한 내용은 Kubernetes에서 비공개 DNS 영역 및 업스트림 네임서버 구성을 참조하세요.

CI/CD 작업 부하

기존 온프레미스 배포에서 시작되는 다중 클라우드 작업 부하는 보다 집중된 작업 부하를 클라우드 환경으로 이전하는 이점을 얻을 수 있습니다.

클라우드 환경에서 컴퓨팅 리소스를 자동으로 확장함으로써 코드 완료부터 아티팩트 제작까지의 시간을 줄일 수 있기 때문에 CI(지속적 통합) 작업 부하는 이전에 적합한 대상입니다.

CD(지속적 배포) 작업 부하도 클라우드 환경에서 실행되는 이점을 활용해서 테스트 환경을 더 쉽게 프로비저닝하고 배포할 수 있습니다. 이전 작업은 단위 테스트를 위한 병렬 빌드 프로세스 수를 늘릴 수 있습니다. 또 다른 잠재적인 이점은 엔드 투 엔드 통합 테스트 및 기타 자동화된 테스트를 위한 테스트 배포 수의 증가입니다.

클라우드 기반의, 컨테이너 중심의 CI/CD 작업 부하에는 일반적으로 다음과 같은 높은 수준의 프로세스가 사용됩니다.

  • 개발. 개발자가 코드 변경 사항을 커밋하고 로컬 또는 원격에서 호스팅되는 소스 저장소에 푸시합니다.
  • 빌드. 빌드 서비스가 소스 코드 저장소를 지속적으로 폴링합니다. 새 변경 사항이 발견되면 서비스가 빌드 프로세스를 시작합니다.
  • 단위 테스트. 프로세스가 소스를 빌드하고, 단위 테스트를 실행하고, 결과 컨테이너 이미지를 빌드합니다.
  • 통합 테스트. 프로세스가 테스트 클러스터를 만들고, 연관된 아티팩트와 함께 컨테이너 이미지를 배포하고, 통합 테스트를 실행합니다.
  • 베이킹. 성공적으로 완료되면 컨테이너 이미지가 출시 버전 메타데이터로 태그 지정됩니다.
  • 배포. 선택적으로 개발자 또는 관리자가 새 아티팩트를 프로덕션에 배포할 수 있습니다.

사용 사례

GCP에서 가장 일반적으로 사용되는 CI/CD 도구는 JenkinsSpinnaker입니다. Jenkins는 독립형 컴퓨팅 인스턴스에 또는 Kubernetes에서 일련의 포드 및 서비스로 배포할 수 있는 인기 있는 오픈소스 CI/CD 시스템입니다. Spinnaker는 여러 대상으로의 소프트웨어 제공을 조정 및 자동화할 수 있는 오픈소스 CD 시스템입니다. Spinnaker는 Jenkins와 같은 CI 시스템 또는 Cloud Build와 같은 다른 도구를 활용할 수 있습니다.

Jenkins 및 Kubernetes

Kubernetes에서 Jenkins를 사용하는 CI/CD 작업 부하의 경우, 다음 문서를 참조하여 권장사항, 일반적인 구성 패턴, 지속적 배포 조정을 검토하세요.

Spinnaker

Spinnaker는 소프트웨어 배포 워크플로 및 클러스터 관리를 조정할 수 있는 오픈소스 기반의 다중 클라우드 CD 플랫폼입니다. Spinnaker의 클러스터 관리 기능은 인스턴스 그룹, 인스턴스, 방화벽, 부하 분산기와 같은 클라우드 리소스를 프로비저닝하고 제어하는 기능을 제공합니다. 소프트웨어 배포 워크플로는 파이프라인으로 구성되며, 이러한 각 파이프라인은 단계라고 부르는 일련의 작업으로 구성됩니다. Spinnaker 파이프라인에서 하나의 단계는 매개변수를 다음 단계로 전달할 수 있습니다. 파이프라인은 수동으로 시작하거나 외부 CI 시스템, cron 스크립트 또는 다른 파이프라인과 같은 자동 트리거를 통해 시작할 수 있습니다. Spinnaker에는 이미지 베이킹, 이미지 배포, 인스턴스 그룹 작업, 사용자 입력 요청을 위한 몇 가지 사전 패키징된 단계와 함께 제공됩니다. 다음 이미지는 Spinnaker 파이프라인이 소프트웨어를 릴리스하는 방법을 보여줍니다.

Spinnaker 파이프라인

소프트웨어가 빌드된 후 테스트됩니다. 모든 테스트를 통과하면 변경할 수 없는 이미지가 베이킹되고 클라우드에 제공됩니다. 이미지가 제공된 다음에는 이를 클러스터에 배포하여 실행 중인 소프트웨어를 업데이트할 수 있습니다.

아키텍처

컨테이너 배포를 작업할 때 Spinnaker는 Jenkins 또는 Cloud Build와 같은 외부 CI 시스템을 사용해서 빌드, 테스트, 베이킹 단계를 실행합니다. 그런 후 Spinnaker는 표준 파이프라인 단계를 사용해서 대상 배포를 조정합니다. 다음 이미지는 이러한 시스템의 아키텍처를 보여줍니다.

Jenkins와 Spinnaker

GCP에서 Spinnaker 배포에 대한 자세한 내용은 Compute Engine에서 Spinnaker 실행을 참조하세요.

Jenkins로 빌드

Jenkins는 트리거가 파이프라인을 시작하도록 지원하는 Spinnaker에서 효과적으로 사용됩니다. Jenkins 빌드를 사용하면 Spinnaker 파이프라인을 자동으로 트리거할 수 있습니다. Spinnaker 파이프라인에서 Jenkins 스크립트 단계는 테스트를 실행하고 릴리스 프로세스의 단계를 베이킹할 수 있습니다. Spinnaker의 기본 제공되는 클러스터 관리 단계는 대상 배포를 조정할 수 있습니다. 자세한 내용은 Spinnaker Hello 배포 예제를 참조하세요.

Cloud Build로 빌드

Cloud Build는 빠르고, 일관적이며, 신뢰할 수 있는 환경에서 컨테이너 이미지를 빌드하는 완전 관리형 GCP 서비스입니다. Cloud Build는 Cloud Source Repositories와 직접 통합되어 소스 또는 저장소 태그의 변경사항을 기준으로 빌드를 자동으로 트리거합니다. Cloud Build는 Docker 컨테이너에서 빌드를 실행하며, 컨테이너에 패키지화할 수 있는 모든 커스텀 빌드 단계를 지원할 수 있습니다. Cloud Build에서 빌드는 세부적으로 맞춤설정할 수 있으며, 단계 시퀀싱 및 동시성을 지원합니다. 빌드 프로세스에서 상태 변경사항은 Cloud Pub/Sub 주제에 자동으로 게시됩니다.

Spinnaker는 Cloud Build를 직접 지원하지 않지만, Cloud Build에서 자동으로 사용되는 Container Registry에 대한 지원을 제공합니다. 업데이트된 컨테이너 이미지 버전 또는 태그 감지를 기준으로 Container Registry를 폴링하고 파이프라인을 시작하도록 Spinnaker를 구성할 수 있습니다. 이러한 시나리오에서는 릴리스 프로세스의 빌드, 테스트, 베이킹 단계를 실행하도록 Cloud Build를 구성해야 합니다. Container Registry를 활용하도록 Spinnaker를 구성하는 방법에 대한 자세한 내용은 Spinnaker 문서를 참조하세요.

Kubernetes 배포 조정

Spinnaker의 기본 제공되는 클러스터 관리 메커니즘에서는 Kubernetes가 지원됩니다. Spinnaker의 서버 그룹과 부하 분산기는 Kubernetes 내의 복제본 집합과 서비스에 해당합니다.

다음 문서에서는 포드 및 서비스를 Kubernetes에 배포하기 위해 Spinnaker를 구성할 때 필요한 단계를 설명합니다.

다음 단계

  • 다른 Google Cloud Platform 기능을 직접 사용해 봅니다. 가이드를 참조하세요.
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...