Kubernetes: Up and Running, 제3판

22장. 애플리케이션 구성하기

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

이 책 전체에서 우리는 Kubernetes를 기반으로 구축된 애플리케이션의 다양한 구성 요소를 설명했습니다. 프로그램을 컨테이너로 래핑하고, 해당 컨테이너를 파드에 배치하고, 레플리카셋으로 해당 파드를 복제하고, 배포를 통해 롤아웃하는 방법에 대해 설명했습니다. 심지어 이러한 객체를 하나의 분산 시스템으로 수집하는 스테이트풀 및 실제 애플리케이션을 배포하는 방법도 설명했습니다. 그러나 실제로 그러한 애플리케이션을 실용적인 방식으로 사용하는 방법은 다루지 않았습니다. 애플리케이션을 구성하는 다양한 구성을 어떻게 배치하고, 공유하고, 관리하고, 업데이트할 수 있을까요? 이것이 이 장의 주제입니다.

우리를 안내하는 원칙

애플리케이션을 구조화하는 방법에 대한 구체적인 세부 사항을 살펴보기 전에 이 구조를 추진하는 목표를 고려하는 것이 좋습니다. 분명히 안정성과 민첩성은 Kubernetes에서 Cloud 네이티브 애플리케이션을 개발하는 일반적인 목표이지만, 이것이 애플리케이션의 유지 관리 및 배포를 설계하는 방법과 어떤 관련이 있을까요? 다음 섹션에서는 이러한 목표에 가장 적합한 구조를 설계하는 데 도움이 될 수 있는 세 가지 원칙을 설명합니다. 원칙은 다음과 같다:

• 파일 시스템을 진실의 원천으로 취급

• 코드 검토를 수행하여 변경 사항의 품질을 보장하세요.

• 기능 플래그를 사용하여 롤아웃 및 롤백 준비하기

진실의 원천으로서의 파일 시스템

이 책의 서두에서 설명한 것처럼, Kubernetes를 처음 탐색하기 시작하면 일반적으로 필수적으로 상호작용하게 됩니다. kubectl run 또는 kubectl edit 같은 명령을 실행하여 클러스터에서 실행 중인 파드나 기타 오브젝트를 생성하고 수정합니다. 우리가 YAML 파일을 작성하고 사용하는 방법을 살펴보기 시작했을 때도, 이것은 마치 파일 자체가 클러스터의 상태를 수정하는 길에 있는 중간 기착지인 것처럼 임시방편적인 방식으로 제시되었습니다. 실제로는 실제 프로덕션 애플리케이션에서는 그 반대가 되어야 합니다.

클러스터의 상태( etcd의 데이터)를 진실의 출처로 보는 대신, 애플리케이션의 진실의 출처로 YAML 객체의 파일 시스템을 보는 것이 가장 좋습니다. 그러면 Kubernetes 클러스터에 배포된 API 오브젝트는 파일시스템에 저장된 진실을 반영합니다.

이것이 올바른 관점인 이유는 여러 가지가 있습니다. 가장 먼저는 클러스터를 불변의 인프라처럼 취급할 수 있다는 점입니다. Cloud 네이티브 아키텍처로 전환하면서 애플리케이션과 그 컨테이너가 불변의 인프라라는 개념에 점점 익숙해졌지만 클러스터를 그렇게 취급하는 것은 덜 일반적입니다. 하지만 애플리케이션을 변경 불가능한 인프라로 옮기는 것과 동일한 이유가 클러스터에도 적용됩니다. 클러스터가 인터넷에서 임시로 다운로드한 임의의 YAML 파일을 적용하여 만든 스노우플레이크라면, ...