컨테이너 오케스트레이션이 중요한 이유는 무엇인가요?

완료됨

이 단원에서는 Tailspin 팀을 따라 관리에서 새 지시문을 제공하기 위한 전략을 살펴볼 수 있습니다. 팀은 Kubernetes가 마이크로 서비스 아키텍처로 전환하는 데 어떻게 도움을 줄 수 있는지 살펴봅니다.

관리가 보다 용이해진 미래

Tailspin의 상황은 점점 더 좋아지고 있습니다. 최근 관리 오프사이트에서 Andy는 팀이 최근에 Azure DevOps를 성공적으로 활용했다는 사실을 발표했으며 이러한 사실은 많은 수긍을 얻었습니다. 또한 Andy는 Docker 컨테이너를 사용하여 팀의 최근 개념 증명 프로젝트에 대한 데모도 제공했습니다. 이러한 데모는 조직의 기술적 미래에 대한 일련의 생산적인 대화로 이어졌습니다. 다음 날 Andy는 돌아와 Space Game 웹 팀과 뉴스를 공유합니다.

Andy: 어제 현장에서 진행된 프레젠테이션은 정말 좋았습니다. 경영진은 지금까지 우리가 진행한 성과에 깊은 인상을 받았으며 특별 업무를 맡겼습니다.

Tim: 아이고. 저는 덫이랑 다를바 없는 느낌을 받았네요.

Andy: 그렇지 않아요. 이것은 정말 좋은 기회입니다. 경영진은 우리가 제시한 Docker 컨테이너 데모를 마음에 들어했으며 마이크로 서비스 아키텍처 채택에 대해서도 살펴보았으면 하고 생각하고 있습니다.

Amita: 마이크로 서비스요? 휴대폰 및 워치용 앱 같은 것인가요?

Andy: 아니요, 마이크로 서비스는 웹앱과 같은 일반적인 앱입니다. 주요 차이점은 단일 모놀리식 앱을 빌드하고 배포하는 대신, 자치 서비스로 더 잘 유지되고 관리되도록 모든 구성 요소를 리팩터링한다는 것입니다. 그런 다음, 독립적인 방식으로 원래 기능을 잘 수행하고 작동하도록 이러한 서비스를 빌드합니다.

Tim: 그런 방식이 괜찮을지 잘 모르겠어요. 저는 이미 업무 환경 전체에서 많은 서비스를 처리하고 있습니다. 더 많은 작업을 맡고 싶지는 않아요.

Andy: 타당한 생각입니다. 다행히 지정된 환경에서 다양한 컨테이너를 관리하기 위한 몇 가지 훌륭한 도구가 있습니다. Kubernetes를 사용하여 오케스트레이션되는 웹앱용 다중 컨테이너 솔루션을 파격적으로 늘리라는 요청을 받았습니다. 또한 경영진은 이 솔루션이 DevOps 프로세스에 미치는 영향을 알고 싶어합니다.

Mara: 저는 Kubernetes에 대해 많은 조사를 해왔는데요. Azure는 Azure Kubernetes Service를 통해 이 기능을 잘 지원하고 있습니다. Azure DevOps에서 파이프라인도 지원된다는 사실도 잘 알고 있습니다.

Amita: 이 프로세스는 복잡해질 것 같아요. 테스트에는 어떤 영향을 미치게 될까요?

Mara: 크게 달라지지는 않을 것입니다. Kubernetes는 다른 네임스페이스에 배포할 수 있는 방법을 제공합니다. 따라서 테스트 전용 환경과 프로덕션 전용 환경에서 사용할 수 있도록 배포를 분할할 수 있습니다. 그리고 둘 다 동일한 클러스터에서 실행되고 동일한 컨테이너를 사용하기 때문에 테스트 환경은 프로덕션에서 예상되는 사항을 제공해야 합니다.

Amita: 어떤 환경이 어디에 있는지 추적하기는 어렵지 않을까요?

Mara: 그렇지 않아요. Azure DevOps 환경을 사용하여 이 모든 작업을 수행할 수 있습니다. Portal을 사용하여 각 서비스가 어디에 있고 어떻게 해당 환경에 도달하는지 확인할 수 있습니다. 모두가 파이프라인을 통해 자동화되므로 수동으로 추적할 필요가 없습니다. 이를 구축할 때 관건은 개발 환경에 얼마나 큰 영향을 미칠게 될 것인가입니다.

Andy: 좋은 소식은 영향이 최소화된다는 것입니다. 우리 프로젝트가 Docker 컨테이너를 빌드하도록 설정되었다고 가정하면 Kubernetes에는 서비스 및 해당 배포를 설명하는 일부 매니페스트 파일만 배포하면 됩니다.

Mara: 두 번째 컨테이너로 리팩터리할 항목에 대해 생각해보셨나요? 제가 알기로 여러 팀에서 웹 API를 통해 순위표를 제공할 것을 요청했습니다.

Andy: 제가 한 발 빨랐네요. 어젯 밤에 Docker 프로젝트를 포크하고 순위표 데이터 기능을 자체 마이크로 서비스로 리팩터링했습니다. 이렇게 하면 웹 사이트용 컨테이너 하나와 순위표 API용 컨테이너가 1개 있게 됩니다. 두 컨테이너는 앱에서 사용하는 기술 스택에 관계없이 사이트 또는 API를 사용하려는 모든 사람과 공유할 수 있는 고유한 퍼블릭 엔드포인트를 갖도록 구성됩니다. 둘 중 하나에 대해 부하가 크게 증가하면 컨테이너를 독립적으로 스케일링할 수 있습니다.

Mara: 이 프로젝트는 정말 대단하네요! 이제 릴리스 파이프라인 업데이트에 대해 논의해보겠습니다.

Kubernetes란?

Kubernetes는 컨테이너화된 애플리케이션의 배포, 크기 조정 및 관리를 자동화하는 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다. 선언적이고 응답성이 뛰어난 방식으로 분산 시스템을 실행하기 위한 프레임워크를 제공하며 여러 호스트에서 컨테이너를 실행하여 리소스를 효율적으로 사용하고 안정성을 높일 수 있습니다.

Tailspin 팀은 이 시나리오에서 Kubernetes 컨테이너를 선택했습니다. Docker 컨테이너가 팀의 모든 필요를 충족했기 때문이었습니다.

  • Kubernetes는 컨테이너의 배포 및 유지 관리와 관련된 프로세스를 자동화하기 위해 가장 먼저 설계되었습니다.

  • 여러 환경 및 단계에서의 일관성: 컨테이너가 포함된 앱에 대해 일관된 배포를 보장하는 것처럼 Kubernetes도 클러스터가 관리하는 컨테이너에 대해 일관된 배포를 보장합니다.

  • Azure DevOps 지원: Azure DevOps는 Kubernetes 작업을 위한 최고 수준의 지원을 제공합니다.

  • 쉬운 개발: Kubernetes가 원본 프로젝트에 미치는 영향은 최소로 유지되며 선언적 구성으로 제한되는 Docker 지원을 추가할 때와 비슷합니다.

Kubernetes를 채택하면 여러 Docker 컨테이너를 사용하는 마이크로 서비스 아키텍처를 채택하는 프로세스가 크게 간소화됩니다.

지식 점검

1.

다음 중에서 마이크로 서비스를 사용하는 적절한 이유가 아닌 것은 무엇인가요?

2.

Docker와 Kubernetes는 어떤 면에서 유사한가요?

3.

팀에서 여러 Docker 컨테이너를 생성하는 솔루션에 여러 .NET Core 프로젝트를 보유하고 있다고 가정합니다. Kubernetes 지원을 추가하는 데 필요한 오버헤드는 얼마나 됩니까?