쿠버네티스란? 대표적인 컨테이너 오케스트레이션 플랫폼 소개

쿠버네티스 모니터링 가이드를 통해, 쿠버네티스에 대한 옵저버빌리티를 확보하는 방법을 알아보고, Pixie의 오토 텔레메트리에 대한 FutureStack 세션을 시청하십시오.

컨테이너 기반의 마이크로서비스 아키텍처는 개발 팀과 운영 팀이 최신 소프트웨어를 테스트하고 배포하는 방식을 크게 바꾸어 놓았습니다. 컨테이너는 애플리케이션을 보다 쉽게 확장하고 배포할 수 있도록 함으로써, 기업의 현대화에 도움을 주지만, 완전히 새로운 인프라 에코시스템을 생성하여 새로운 도전과제와 더 많은 복잡성을 야기합니다.

모든 규모의 소프트웨어 기업들이 이제 매일 수천 개의 컨테이너 인스턴스를 배포하고 있습니다. 이는 관리가 한층 더 복잡해졌다는 의미입니다. 그렇다면, 기업들은 이에 어떻게 대처하고 있을까요?

쿠버네티스의 시대가 열렸습니다.

Google에서 개발한 쿠버네티스(Kubernetes)는 오픈소스 컨테이너 오케스트레이션 플랫폼으로, 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하도록 설계되었습니다. 실제로, 쿠버네티스는 컨테이너 오케스트레이션을 위한 사실상의 표준으로 자리를 잡았으며, CNCF(Cloud Native Computing Foundation), Google, AWS, Microsoft, IBM, Intel, Cisco 및 Red Hat과 같은 주요 업체들이 이를 지원합니다.

쿠버네티스는 마이크로서비스 아키텍처에서 애플리케이션을 쉽게 배포하고 운영할 수 있게 합니다. 호스트 그룹 위에 추상화 계층을 생성하여, 개발 팀이 애플리케이션을 배포할 수 있도록 하고, 쿠버네티스가 다음 활동을 관리해주기 때문입니다.

• 애플리케이션 또는 팀별 리소스 소비 제어
• 호스트 인프라 전반에 애플리케이션 로드를 균등하게 분산
• 애플리케이션의 여러 인스턴스에 자동으로 요청 로드 밸런싱
• 리소스 소비와 리소스 한도를 모니터링하여 애플리케이션들이 과도한 리소스를 소비하고 재시작되지 않도록 자동으로 방지
• 호스트에 리소스가 부족하거나 호스트가 종료된 경우, 한 호스트에서 다른 호스트로 애플리케이션 인스턴스 이동
• 새 호스트가 클러스터에 추가될 때 사용할 수 있는 추가 리소스를 자동으로 활용
• 손쉽게 카나리아 배포 및 롤백 수행

그런데 쿠버네티스는 왜 그렇게 많은 관심을 받으며 인기를 끌고 있을까요?

점점 더 많은 조직들이 컨테이너를 사용하는 마이크로서비스와 클라우드 네이티브 아키텍처로 이동하면서, 강력하고 입증된 플랫폼을 찾고 있기 때문입니다. 실무자들이 쿠버네티스로 이동하는 주요 이유 네 가지는 다음과 같습니다.

1. 쿠버네티스는 개발을 가속화할 수 있도록 지원합니다. 쿠버네티스를 사용하면 개발 팀을 위해 하드웨어 추상화 계층을 생성해주는 ‘서비스로서의 셀프 서비스 플랫폼(Platform-as-a-Service, PaaS)을 제공할 수 있습니다. 개발 팀은 필요한 리소스를 빠르고 효율적으로 요청할 수 있습니다. 또한 추가적인 로드를 처리하기 위해 더 많은 리소스가 필요한 경우, 모든 리소스가 모든 팀들이 공유하는 인프라에서 제공되므로 리소스를 빠르게 얻을 수 있습니다.

애플리케이션을 실행하기 위해 새 컴퓨터를 요청하지 않아도 됩니다. 프로비저닝을 하기만 하면, 패키징, 배포 및 테스트를 자동화하는 데 쿠버네티스용으로 개발된 tool을 활용할 수 있습니다. (헬름(Helm)에 대해서는 다음 섹션에서 자세히 다루겠습니다.)

2. 쿠버네티스는 비용 효율적입니다. 쿠버네티스와 컨테이너는 하이퍼바이저와 가상머신(VM)보다 훨씬 더 효율적으로 리소스를 활용할 수 있게 해줍니다. 컨테이너는 매우 가볍기 때문에, 실행하는 데 필요한 CPU와 메모리 리소스가 적습니다.

3. 쿠버네티스는 클라우드에 구애를 받지 않습니다. 쿠버네티스는 Amazon Web Services(AWS), Microsoft Azure, Google Cloud Platform(GCP)에서 실행되며, 온프레미스에서도 실행할 수 있습니다. 애플리케이션을 다시 설계하거나 인프라를 완전히 재구성하지 않아도 워크로드를 이동할 수 있기 때문에, 단일 플랫폼에서 표준화할 수 있고, 특정 공급업체에 종속되지 않아도 됩니다.

실제로, Kublr, Foundry, Rancher 같은 기업들은 온프레미스나 클라우드 제공업체에서 쿠버네티스 클러스터를 배포하고 관리할 수 있도록 지원하는 tool을 제공합니다.

4. 클라우드 제공업체가 쿠버네티스를 관리해줍니다. 앞서 언급했듯이, 쿠버네티스는 이제 컨테이너 오케스트레이션 tool의 표준으로 자리를 잡았습니다. 주요 클라우드 제공업체가 다양한 서비스로서 쿠버네티스를 제공하고 있다는 것은 놀라운 일이 아닙니다. Amazon EKS, Google Cloud Kubernetes Engine, AKS(Azure Kubernetes Service), Red Hat OpenShift 및 IBM Cloud Kubernetes 서비스는 모두 완전한 쿠버네티스 플랫폼 관리 기능을 제공하기 때문에, 기업은 가장 중요한 일 즉, 사용자를 만족시키는 애플리케이션을 제공하는 데만 집중할 수 있습니다.

쿠버네티스는 어떤 원리로 작동할까요?

쿠버네티스의 핵심 구성 요소는 클러스터입니다. 클러스터는 각각 마스터 또는 노드로서 고유한 기능을 제공하는 여러 가상 또는 물리적 시스템으로 구성됩니다. 각 노드는 하나 이상의 컨테이너(애플리케이션 포함) 그룹을 호스팅하고, 마스터는 컨테이너를 생성하거나 삭제할 시기에 대해 노드와 통신을 합니다. 동시에, 새로운 컨테이너 정렬을 기반으로 어떻게 트래픽을 다시 라우팅할지를 노드에게 알려줍니다.

다음 다이어그램은 쿠버네티스 클러스터를 간략하게 표현한 것입니다.

컨테이너 기반의 마이크로서비스 아키텍처는 개발 팀과 운영 팀이 최신 소프트웨어를 테스트하고 배포하는 방식을 크게 바꾸어 놓았습니다. 컨테이너는 애플리케이션을 보다 쉽게 확장하고 배포할 수 있도록 함으로써, 기업의 현대화에 도움을 주지만, 완전히 새로운 인프라 에코시스템을 생성하여 새로운 도전과제와 더 많은 복잡성을 야기합니다.

모든 규모의 소프트웨어 기업들이 이제 매일 수천 개의 컨테이너 인스턴스를 배포하고 있습니다. 이는 관리가 한층 더 복잡해졌다는 의미입니다. 그렇다면, 기업들은 이에 어떻게 대처하고 있을까요?

쿠버네티스의 시대가 열렸습니다.

Google에서 개발한 쿠버네티스(Kubernetes)는 오픈소스 컨테이너 오케스트레이션 플랫폼으로, 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하도록 설계되었습니다. 실제로, 쿠버네티스는 컨테이너 오케스트레이션을 위한 사실상의 표준으로 자리를 잡았으며, CNCF(Cloud Native Computing Foundation), Google, AWS, Microsoft, IBM, Intel, Cisco 및 Red Hat과 같은 주요 업체들이 이를 지원합니다.

쿠버네티스는 마이크로서비스 아키텍처에서 애플리케이션을 쉽게 배포하고 운영할 수 있게 합니다. 호스트 그룹 위에 추상화 계층을 생성하여, 개발 팀이 애플리케이션을 배포할 수 있도록 하고, 쿠버네티스가 다음 활동을 관리해주기 때문입니다.

• 애플리케이션 또는 팀별 리소스 소비 제어
• 호스트 인프라 전반에 애플리케이션 로드를 균등하게 분산
• 애플리케이션의 여러 인스턴스에 자동으로 요청 로드 밸런싱
• 리소스 소비와 리소스 한도를 모니터링하여 애플리케이션들이 과도한 리소스를 소비하고 재시작되지 않도록 자동으로 방지
• 호스트에 리소스가 부족하거나 호스트가 종료된 경우, 한 호스트에서 다른 호스트로 애플리케이션 인스턴스 이동
• 새 호스트가 클러스터에 추가될 때 사용할 수 있는 추가 리소스를 자동으로 활용
• 손쉽게 카나리아 배포 및 롤백 수행

그런데 쿠버네티스는 왜 그렇게 많은 관심을 받으며 인기를 끌고 있을까요?

점점 더 많은 조직들이 컨테이너를 사용하는 마이크로서비스와 클라우드 네이티브 아키텍처로 이동하면서, 강력하고 입증된 플랫폼을 찾고 있기 때문입니다. 실무자들이 쿠버네티스로 이동하는 주요 이유 네 가지는 다음과 같습니다.

1. 쿠버네티스는 개발을 가속화할 수 있도록 지원합니다. 쿠버네티스를 사용하면 개발 팀을 위해 하드웨어 추상화 계층을 생성해주는 ‘서비스로서의 셀프 서비스 플랫폼(Platform-as-a-Service, PaaS)을 제공할 수 있습니다. 개발 팀은 필요한 리소스를 빠르고 효율적으로 요청할 수 있습니다. 또한 추가적인 로드를 처리하기 위해 더 많은 리소스가 필요한 경우, 모든 리소스가 모든 팀들이 공유하는 인프라에서 제공되므로 리소스를 빠르게 얻을 수 있습니다.

애플리케이션을 실행하기 위해 새 컴퓨터를 요청하지 않아도 됩니다. 프로비저닝을 하기만 하면, 패키징, 배포 및 테스트를 자동화하는 데 쿠버네티스용으로 개발된 tool을 활용할 수 있습니다. (헬름(Helm)에 대해서는 다음 섹션에서 자세히 다루겠습니다.)

2. 쿠버네티스는 비용 효율적입니다. 쿠버네티스와 컨테이너는 하이퍼바이저와 가상머신(VM)보다 훨씬 더 효율적으로 리소스를 활용할 수 있게 해줍니다. 컨테이너는 매우 가볍기 때문에, 실행하는 데 필요한 CPU와 메모리 리소스가 적습니다.

3. 쿠버네티스는 클라우드에 구애를 받지 않습니다. 쿠버네티스는 Amazon Web Services(AWS), Microsoft Azure, Google Cloud Platform(GCP)에서 실행되며, 온프레미스에서도 실행할 수 있습니다. 애플리케이션을 다시 설계하거나 인프라를 완전히 재구성하지 않아도 워크로드를 이동할 수 있기 때문에, 단일 플랫폼에서 표준화할 수 있고, 특정 공급업체에 종속되지 않아도 됩니다.

실제로, Kublr, Foundry, Rancher 같은 기업들은 온프레미스나 클라우드 제공업체에서 쿠버네티스 클러스터를 배포하고 관리할 수 있도록 지원하는 tool을 제공합니다.

4. 클라우드 제공업체가 쿠버네티스를 관리해줍니다. 앞서 언급했듯이, 쿠버네티스는 이제 컨테이너 오케스트레이션 tool의 표준으로 자리를 잡았습니다. 주요 클라우드 제공업체가 다양한 서비스로서 쿠버네티스를 제공하고 있다는 것은 놀라운 일이 아닙니다. Amazon EKS, Google Cloud Kubernetes Engine, AKS(Azure Kubernetes Service), Red Hat OpenShift 및 IBM Cloud Kubernetes 서비스는 모두 완전한 쿠버네티스 플랫폼 관리 기능을 제공하기 때문에, 기업은 가장 중요한 일 즉, 사용자를 만족시키는 애플리케이션을 제공하는 데만 집중할 수 있습니다.

쿠버네티스는 어떤 원리로 작동할까요?

쿠버네티스의 핵심 구성 요소는 클러스터입니다. 클러스터는 각각 마스터 또는 노드로서 고유한 기능을 제공하는 여러 가상 또는 물리적 시스템으로 구성됩니다. 각 노드는 하나 이상의 컨테이너(애플리케이션 포함) 그룹을 호스팅하고, 마스터는 컨테이너를 생성하거나 삭제할 시기에 대해 노드와 통신을 합니다. 동시에, 새로운 컨테이너 정렬을 기반으로 어떻게 트래픽을 다시 라우팅할지를 노드에게 알려줍니다.

다음 다이어그램은 쿠버네티스 클러스터를 간략하게 표현한 것입니다.

쿠버네티스 마스터

쿠버네티스 마스터는 관리자 및 다른 사용자가 클러스터와 상호 작용을 하고, 컨테이너의 스케줄링 및 배포를 관리하는 액세스 포인트(또는 제어 플레인)입니다. 클러스터에는 반드시 하나 이상의 마스터가 존재하지만, 클러스터의 복제 패턴에 따라 더 많은 마스터가 있을 수도 있습니다.

마스터는 전체 클러스터의 상태 및 설정 데이터를 영구적이고 분산된 키-값 데이터 저장소인 etcd에 저장합니다. 각 노드는 ectd에 액세스할 수 있으며, 이를 통해 실행 중인 컨테이너의 설정을 유지하는 방법을 학습합니다. 쿠버네티스 마스터에서, 또는 독립적인 설정을 통해 etcd를 실행할 수 있습니다.

마스터는 컨트롤 플레인의 기본 액세스 포인트인 kube-apiserver를 통해 클러스터의 나머지 부분과 통신합니다. 예를 들어, kube-apiserver는 etcd의 설정이 클러스터에 배포된 컨테이너의 설정과 일치하도록 합니다.

kube-controller-manager는 쿠버네티스 API 서버를 통해 클러스터의 상태를 관리하는 제어 루프를 처리합니다. 배포, 복제본 및 노드에는 이 서비스로 처리되는 컨트롤 기능이 있습니다. 예를 들어, 노드 컨트롤러는 노드를 등록하고 수명주기 동안 상태를 모니터링합니다.

클러스터의 노드 워크로드는 kube-scheduler로 추적 및 관리됩니다. 이 서비스는 노드의 용량과 리소스를 추적하고, 가용성에 기반해 작업을 노드에 할당합니다.

cloud-controller-manager는 쿠버네티스에서 실행되는 서비스로, 서비스가 특정 클라우드에 종속되지 않도록 합니다. cloud-controller-manager는 클라우드 제공업체의 API 및 tool(예: 스토리지 볼륨 또는 로드 밸런서)과 쿠버네티스에 있는 상응 요소들의 카운터파트 역할을 합니다.

노드

쿠버네티스 클러스터의 모든 노드는 일반적으로 도커(Docker) 같은 컨테이너 런타임으로 설정되어야 합니다. 컨테이너 런타임은 쿠버네티스가 컨테이너를 클러스터의 노드에 배포할 때 컨테이너를 시작하고 관리합니다. 애플리케이션(웹 서버, 데이터베이스, API 서버 등)은 컨테이너 내부에서 실행됩니다.

각 쿠버네티스 노드는 큐블릿(Kubelet)이라 불리는 에이전트 프로세스를 실행합니다. 큐블릿은 노드의 상태를 관리하며, 컨트롤 플레인의 명령에 따라 애플리케이션 컨테이너를 시작, 중지 및 유지 관리합니다. 큐블릿은 실행되는 노드, 포드 및 컨테이너에서 성능 및 상태 정보를 수집합니다. 이 정보를 컨트롤 플레인과 공유하여 스케줄링 결정을 내립니다.

Kube-proxy는 클러스터의 노드에서 실행되는 네트워크 프록시입니다. 또한 노드에서 실행되는 서비스의 로드 밸런서의 역할을 합니다.

스케줄링의 기본 단위는 포드(pod)이며, 포드는 호스트 시스템에 함께 배치되어 리소스를 공유하는 하나 이상의 컨테이너로 구성됩니다. 클러스터 내의 각 포드에는 고유한 IP 주소가 할당되어, 애플리케이션이 충돌없이 포트를 사용할 수 있도록 합니다.

포드 스펙(Pod Spec)이라고 불리는 YAML 또는 JSON 오브젝트를 통해 포드에 있는 컨테이너의 이상적인 상태를 설명하면, 이러한 오브젝트가 API 서버를 통해 큐블릿에 전달됩니다.

포드는 로컬 디스크, 네트워크 디스크 등 하나 이상의 볼륨을 정의하여 포드의 컨테이너에 노출시킴으로써, 여러 컨테이너들이 스토리지 공간을 공유할 수 있도록 합니다. 예를 들어, 볼륨을 사용해 한 컨테이너로는 콘텐츠를 다운로드하고, 다른 컨테이너로는 해당 콘텐츠를 다른 곳에 업로드할 수 있습니다. 포드 내부의 컨테이너는 보통 임시적이므로, 쿠버네티스는 포드 그룹에 대한 요청 전송을 간소화하기 위해 ‘서비스(service)’라고 하는 로드 밸런서 유형을 제공합니다. 서비스(Service)는 라벨(아래 설명)에 기반해 선택된 논리적 포드 세트를 타깃으로 삼습니다. 기본적으로, 서비스는 클러스터 내에서만 액세스할 수 있지만, 퍼블릭 액세스를 활성화하여 클러스터 외부에서 요청을 받도록 할 수도 있습니다.

디플로이먼트(Deployment) 및 레플리카(replica)

디플로이먼트(Deployment)는 각 포드에 대해 레플리카(replica)라 불리는 포드 및 컨테이너 인스턴스의 수를 정의하는 YAML 오브젝트입니다. 디플로이먼트 오브젝트의 일부인 레플리카셋(ReplicaSet)을 사용해 클러스터에서 실행하려는 복제본 수를 정의합니다. 예를 들어, 포드를 실행하는 노드가 종료되면, 레플리카셋은 다른 포드가 사용 가능한 다른 노드에 스케줄링되도록 합니다.

데몬셋(DaemonSet)은 지정한 노드에 (포드에 포함된) 특정 데몬을 배포하고 실행합니다. 데몬셋은 포드에 서비스 또는 유지 관리를 제공하는 데 가장 많이 사용됩니다. 예를 들어, 뉴렐릭 Infrastructure는 DaemonSet을 사용해 클러스터의 모든 노드에 배포된 인프라 에이전트를 가져옵니다.

네임스페이스(Namespace)

네임스페이스(Namespace)는 물리적 클러스터 위에 가상 클러스터를 생성할 수 있도록 합니다. 네임스페이스는 여러 팀 또는 프로젝트에 분산된, 사용자가 많은 환경에서 사용되며, 리소스 할당량을 할당하고 클러스터 리소스를 논리적으로 격리합니다.

라벨(Label)

라벨(Label)은 쿠버네티스에서 포드 및 기타 오브젝트에 할당할 수 있는 키/값 쌍입니다. 라벨은 쿠버네티스 운영자가 오브젝트들의 하위 집합을 구성하고 선택할 수 있게 합니다. 예를 들어, 쿠버네티스 오브젝트를 모니터링할 때 라벨을 사용하면 가장 관심 있는 정보를 빠르게 분석할 수 있습니다.

스테이트풀셋(StatefulSet) 및 퍼시스턴트 스토리지 볼륨(persistent storage volume)

스테이트풀셋(StatefulSet)은 포드를 다른 노드로 이동하거나, 포드 간에 네트워킹을 유지하는 경우, 또는 노드 간에 데이터를 유지해야 하는 경우, 포드에 고유 ID를 할당할 수 있는 기능을 제공합니다. 마찬가지로, 퍼시스턴트 스토리지 볼륨(persistent storage volume)은 포드가 배포될 때 액세스를 요청하는 클러스터에 스토리지 리소스를 제공합니다.

기타 유용한 구성 요소

다음의 쿠버네티스 구성 요소는 유용하지만, 일반적인 쿠버네티스 사용에는 필요하지 않습니다.

쿠버네티스 DNS

쿠버네티스는 포드 간의 DNS 기반 서비스 검색을 위해 이 메커니즘을 제공합니다. 이 DNS 서버는 인프라에서 사용할 수 있는 모든 다른 DNS 서버와 함께 작동합니다.

클러스터 수준 로그

사용 중인 로깅 tool을 쿠버네티스와 통합하면, 클러스터 내에서 표준 출력 및 표준 오류로 쓰기된 애플리케이션 및 시스템 로그 로그를 추출해 저장할 수 있습니다. 클러스터 수준 로그를 사용하려는 경우, 쿠버네티스는 기본적으로 로그를 저장하지 않는다는 점에 유의해야 합니다. 자체적으로 로그 스토리지 솔루션을 제공해야 합니다.

헬름(Helm): 쿠버네티스 애플리케이션 관리

헬름(Helm)은 CNCF에서 유지 관리하는 쿠버네티스용 애플리케이션 패키지 관리 레지스트리입니다. 헬름 차트는 사전 설정된 소프트웨어 애플리케이션 리소스로, 쿠버네티스 환경에서 다운로드 및 배포할 수 있습니다. 2020 CNCF 설문 조사에서 응답자의 63%는 헬름을 쿠버네티스 애플리케이션에서 가장 선호하는 패키지 관리 tool로 꼽았습니다. 헬름차트는 데브옵스 팀이 쿠버네티스에서 애플리케이션을 보다 신속하게 관리하는 데 도움이 될 수 있습니다. 기존 차트를 개발 및 운영 환경에서 공유, 버전화 및 배포할 수 있도록 해주기 때문입니다.

쿠버네티스와 Istio: 인기 있는 페어링

쿠버네티스에서 실행되는 마이크로서비스 아키텍처에서, 서비스 메시(service mesh)는 서비스 인스턴스가 서로 통신할 수 있도록 해주는 인프라 계층입니다. 서비스 메시는 서비스 인스턴스가 어떻게 서비스 검색, 로드 밸런싱, 데이터 암호화, 인증 및 권한 부여 같은 중요한 작업을 수행할지 설정할 수 있도록 해줍니다. Istio는 이러한 서비스 메시 중 하나로, Google, IBM 같은 기술 리더들에 따르면 앞으로 그 중요성이 점점 더 커질 것으로 보입니다.

예를 들어, IBM Cloud 팀은 Istio를 사용해, 쿠버네티스를 대규모로 배포하는 동안 발생하는 제어, 가시성 및 보안 문제를 해결합니다. Istio는 IBM을 다음과 같은 방식으로 지원합니다.

• 서비스를 함께 연결하고 트래픽 흐름 제어
• 유연한 권한 부여 및 인증 정책으로 마이크로서비스 간의 안전한 상호작용 지원
• IBM이 운영 환경에서 서비스를 관리할 수 있도록 제어 지점 제공
• Istio 데이터를 뉴렐릭으로 전송해 이미 수집 중인 애플리케이션 데이터와 함께 쿠버네티스의 마이크로서비스 성능 데이터를 모니터링할 수 있도록 해주는 어댑터를 통해, 서비스에서 어떤 일이 일어나는지 살펴볼 수 있습니다.

쿠버네티스 도입의 도전과제

쿠버네티스는 지난 5년 동안 장족의 발전을 해왔습니다. 그러한 급속한 성장에는 성장통이 수반되기 마련입니다. 쿠버네티스의 도입과 관련된 몇 가지 도전과제는 다음과 같습니다.

1.쿠버네티스 기술 환경은 혼란스러울 수 있습니다.개발자가 쿠버네티스 같은 오픈소스 기술을 좋아하는 이유 중 하나는 빠른 속도로 혁신이 가능하다는 것입니다. 그러나 과한 혁신은 혼란을 야기하는 경우가 있습니다. 중앙의 쿠버네티스 코드 베이스가 사용자들이 따라 잡을 수 있는 것보다 빠르게 이동하는 경우라면 더욱 그러합니다. 거기에, 수많은 플랫폼과 매니지드 서비스 제공업체들까지 더해지면, 새로운 사용자가 환경을 이해하는 것이 상당히 어려워질 수 있습니다.

2. 미래 지향적인 개발 및 IT 팀의 우선순위가 항상 비즈니스의 우선순위와 부합하지는 않습니다. 예산이 현상 유지를 할 정도로만 할당되는 경우, 팀이 쿠버네티스 도입 이니셔티브를 실험하기 위한 자금을 확보하기 어려울 수 있습니다. 이러한 실험은 보통 상당한 시간과 팀 리소스가 필요하기 때문입니다. 또한 엔터프라이즈 IT 팀은 위험을 기피하려는 경향이 있고 변화의 속도가 느립니다.

3. 팀들은 아직도 쿠버네티스를 활용하는 데 필요한 기술을 습득하고 있습니다. 불과 몇 년 전에, 개발자와 IT 운영 담당자들은 컨테이너를 도입하기 위해 상황을 조정해야 했습니다. 그런데 이제 또 컨테이너 오케스트레이션을 도입해야 합니다. 쿠버네티스를 도입하려는 기업은 애플리케이션 아키텍처, 스토리지 및 데이터 워크플로우를 이해하는 것은 물론 운영을 관리하며 코딩할 수 있는 전문가를 고용해야 합니다.

4. 쿠버네티스는 관리하기 어려울 수 있습니다.실제로, 쿠버네티스 실패 사례 GitHub 저장소를 보면, DNS 중단에서 분산 시스템에 발생하는 연속 장애까지, 쿠버네티스와 관련된 나쁜 경험담이 넘쳐납니다.

뉴렐릭은 쿠버네티스 여정을 지원할 수 있습니다.

기업은 클러스터와 워크로드의 성능을 빠르고 쉽게, 또 완전하게 이해할 수 있는 역량이 필요합니다. 뉴렐릭은 단일한 사용자 인터페이스에서 모든 클러스터를 분석하여 보다 빠르게 문제를 해결할 수 있도록 지원합니다. 코드 업데이트, 앱 재배포, 장시간 소요되는 표준화 프로세스는 필요하지 않습니다. Pixie의 오토 텔레메트리(Auto-telemetry)는 쿠버네티스 클러스터 및 워크로드에 대한 즉각적인 가시성을 제공합니다.

쿠버네티스 클러스터 익스플로러는 모든 쿠버네티스 엔터티(노드, 네임스페이스, 디플로이먼트, 레플리카셋, 포드, 컨테이너 및 워크로드)를 한 곳에서 분석할 수 있도록 지원합니다. 파이 차트의 각 조각은 노드를 나타내고 각 육각형은 포드를 나타냅니다. 관련된 로그 파일 액세스를 포함해, 애플리케이션의 성능을 분석하려면 포드(Pod)를 선택하면 됩니다.

포드 및 애플리케이션의 성능 분석

각 애플리케이션의 분산 트레이스를 분석할 수 있습니다. 각 범위를 클릭하면, 관련된 쿠버네티스 속성(예: 관련 포드, 클러스터, 배포)이 표시됩니다.

또한 클러스터에서 실행되는 애플리케이션에서 분산 추적 데이터를 가져올 수도 있습니다.

Pixie의 오토 텔레메트리로 지금 시작하십시오. (EU 링크).