Kubernetes 소개

소개

Kubernetes는 클러스터 환경에서 컨테이너화된 애플리케이션을 관리하기 위해 Google에서 처음 개발한 강력한 오픈 소스 시스템입니다. 다양한 인프라에서 관련 분산 구성 요소 및 서비스를 관리하는 더 나은 방법을 제공하는 것을 목표로 합니다.

이 가이드에서는 Kubernetes의 기본 개념 중 일부에 대해 설명합니다. 시스템의 아키텍처, 해결하는 문제, 컨테이너화된 배포 및 확장을 처리하는 데 사용하는 모델에 대해 이야기합니다.

쿠버네티스란?

Kubernetes는 기본 수준에서 머신 클러스터 전체에서 컨테이너화된 애플리케이션을 실행하고 조정하기 위한 시스템입니다. 예측 가능성, 확장성 및 고가용성을 제공하는 방법을 사용하여 컨테이너화된 애플리케이션 및 서비스의 수명 주기를 완벽하게 관리하도록 설계된 플랫폼입니다.

Kubernetes 사용자는 애플리케이션 실행 방법과 다른 애플리케이션 또는 외부 세계와 상호 작용할 수 있는 방법을 정의할 수 있습니다. 서비스를 확장 또는 축소하고, 점진적인 롤링 업데이트를 수행하고, 여러 버전의 애플리케이션 간에 트래픽을 전환하여 기능을 테스트하거나 문제가 있는 배포를 롤백할 수 있습니다. Kubernetes는 높은 수준의 유연성, 성능 및 안정성으로 애플리케이션을 정의하고 관리할 수 있는 인터페이스 및 구성 가능한 플랫폼 기본 요소를 제공합니다.

쿠버네티스 아키텍처

쿠버네티스가 이러한 기능을 제공하는 방법을 이해하려면 쿠버네티스가 높은 수준에서 설계되고 구성되는 방식을 이해하는 것이 좋습니다. Kubernetes는 계층에 구축된 시스템으로 시각화할 수 있으며 각 상위 계층은 하위 수준에서 발견되는 복잡성을 추상화합니다.

기본적으로 Kubernetes는 각 서버 간에 통신하기 위해 공유 네트워크를 사용하여 개별 물리적 또는 가상 머신을 클러스터로 통합합니다. 이 클러스터는 모든 Kubernetes 구성 요소, 기능 및 워크로드가 구성된 물리적 플랫폼입니다.

클러스터의 머신에는 각각 Kubernetes 에코시스템 내에서 역할이 부여됩니다. 하나의 서버(또는 고가용성 배포의 소규모 그룹)는 마스터 서버로 작동합니다. 이 서버는 사용자와 클라이언트를 위한 API를 노출하고, 다른 서버의 상태를 확인하고, 작업을 분할하고 할당하는 최선의 방법을 결정하고(\스케줄링\이라고 함) 다른 구성 요소 간의 통신을 오케스트레이션하여 클러스터의 게이트웨이 및 두뇌 역할을 합니다. 마스터 서버는 클러스터와의 기본 접점 역할을 하며 Kubernetes가 제공하는 대부분의 중앙 집중식 논리를 담당합니다.

클러스터의 다른 시스템은 로컬 및 외부 리소스를 사용하여 워크로드를 수락하고 실행하는 서버인 노드로 지정됩니다. 격리, 관리 및 유연성을 지원하기 위해 Kubernetes는 컨테이너에서 애플리케이션 및 서비스를 실행하므로 각 노드에 컨테이너 런타임(예: Docker 또는 rkt)이 장착되어야 합니다. 노드는 마스터 서버로부터 작업 지시를 받고 그에 따라 컨테이너를 생성하거나 파괴하여 네트워킹 규칙을 조정하여 트래픽을 적절하게 라우팅하고 전달합니다.

위에서 언급했듯이 애플리케이션과 서비스 자체는 컨테이너 내의 클러스터에서 실행됩니다. 기본 구성 요소는 애플리케이션의 원하는 상태가 클러스터의 실제 상태와 일치하는지 확인합니다. 사용자는 기본 API 서버와 직접 또는 클라이언트 및 라이브러리와 통신하여 클러스터와 상호 작용합니다. 애플리케이션 또는 서비스를 시작하기 위해 생성할 대상과 관리 방법을 정의하는 선언적 계획이 JSON 또는 YAML로 제출됩니다. 그런 다음 마스터 서버는 계획을 취하고 요구 사항과 시스템의 현재 상태를 검사하여 인프라에서 실행하는 방법을 파악합니다. 지정된 계획에 따라 실행되는 이 사용자 정의 애플리케이션 그룹은 Kubernetes의 최종 계층을 나타냅니다.

마스터 서버 구성 요소

위에서 설명한 것처럼 마스터 서버는 Kubernetes 클러스터의 기본 제어 평면 역할을 합니다. 관리자와 사용자의 주요 접점 역할을 하며 상대적으로 덜 복잡한 작업자 노드를 위해 많은 클러스터 전체 시스템을 제공합니다. 전반적으로 마스터 서버의 구성 요소는 함께 작동하여 사용자 요청을 수락하고, 워크로드 컨테이너를 예약하고, 클라이언트 및 노드를 인증하고, 클러스터 전체 네트워킹을 조정하고, 확장 및 상태 확인 책임을 관리하는 최상의 방법을 결정합니다.

이러한 구성 요소는 단일 시스템에 설치하거나 여러 서버에 분산할 수 있습니다. 이 섹션에서는 마스터 서버와 관련된 각 개별 구성 요소를 살펴보겠습니다.

등

Kubernetes가 작동하는 데 필요한 기본 구성 요소 중 하나는 전역적으로 사용 가능한 구성 저장소입니다. CoreOS 팀에서 개발한 etcd 프로젝트는 여러 노드에 걸쳐 구성할 수 있는 경량의 분산 키-값 저장소입니다.

Kubernetes는 etcd를 사용하여 클러스터의 각 노드에서 액세스할 수 있는 구성 데이터를 저장합니다. 이는 서비스 검색에 사용할 수 있으며 구성 요소가 최신 정보에 따라 자체 구성 또는 재구성하는 데 도움이 될 수 있습니다. 또한 리더 선택 및 분산 잠금과 같은 기능으로 클러스터 상태를 유지하는 데 도움이 됩니다. 간단한 HTTP/JSON API를 제공함으로써 값을 설정하거나 검색하는 인터페이스가 매우 간단합니다.

컨트롤 플레인의 대부분의 다른 구성 요소와 마찬가지로 etcd는 단일 마스터 서버에서 구성하거나 프로덕션 시나리오에서 여러 시스템에 분산하여 구성할 수 있습니다. 유일한 요구 사항은 각 Kubernetes 시스템에서 네트워크에 액세스할 수 있어야 한다는 것입니다.

kube-apiserver

가장 중요한 마스터 서비스 중 하나는 API 서버입니다. 사용자가 Kubernetes의 워크로드 및 조직 단위를 구성할 수 있으므로 전체 클러스터의 주요 관리 지점입니다. 또한 etcd 저장소와 배포된 컨테이너의 서비스 세부 정보가 일치하는지 확인해야 합니다. 클러스터 상태를 유지하고 정보와 명령을 전파하기 위해 다양한 구성 요소 간의 브리지 역할을 합니다.

API 서버는 RESTful 인터페이스를 구현하므로 다양한 도구와 라이브러리가 쉽게 통신할 수 있습니다. kubectl이라는 클라이언트는 로컬 컴퓨터에서 Kubernetes 클러스터와 상호 작용하는 기본 방법으로 사용할 수 있습니다.

kube-컨트롤러-매니저

컨트롤러 관리자는 많은 책임이 있는 일반 서비스입니다. 주로 클러스터의 상태를 조절하고 워크로드 수명 주기를 관리하며 일상적인 작업을 수행하는 다양한 컨트롤러를 관리합니다. 예를 들어, 복제 컨트롤러는 포드에 대해 정의된 복제본(동일한 복사본)의 수가 현재 클러스터에 배포된 수와 일치하는지 확인합니다. 이러한 작업의 세부 정보는 컨트롤러 관리자가 API 서버를 통해 변경 사항을 감시하는 etcd에 기록됩니다.

변경 사항이 확인되면 컨트롤러는 새 정보를 읽고 원하는 상태를 충족하는 절차를 구현합니다. 여기에는 애플리케이션 확장 또는 축소, 엔드포인트 조정 등이 포함될 수 있습니다.

큐브 스케줄러

실제로 클러스터의 특정 노드에 워크로드를 할당하는 프로세스가 스케줄러입니다. 이 서비스는 워크로드의 운영 요구 사항을 읽고 현재 인프라 환경을 분석하고 허용 가능한 노드에 작업을 배치합니다.

스케줄러는 워크로드가 사용 가능한 리소스를 초과하여 예약되지 않도록 각 호스트에서 사용 가능한 용량을 추적하는 역할을 합니다. 스케줄러는 총 용량과 각 서버의 기존 작업 부하에 이미 할당된 리소스를 알아야 합니다.

클라우드 컨트롤러 관리자

Kubernetes는 다양한 환경에 배포할 수 있으며 다양한 인프라 공급자와 상호 작용하여 클러스터의 리소스 상태를 이해하고 관리할 수 있습니다. Kubernetes는 연결 가능한 스토리지 및 로드 밸런서와 같은 리소스의 일반적인 표현과 함께 작동하지만 이를 비동질 클라우드 공급자가 제공하는 실제 리소스에 매핑하는 방법이 필요합니다.

클라우드 컨트롤러 관리자는 Kubernetes가 내부적으로 상대적으로 일반적인 구성을 유지하면서 다양한 기능, 기능 및 API를 사용하여 공급자와 상호 작용할 수 있도록 하는 접착제 역할을 합니다. 이를 통해 쿠버네티스는 클라우드 공급자로부터 수집한 정보에 따라 상태 정보를 업데이트하고, 시스템에서 변경이 필요할 때 클라우드 리소스를 조정하고, 클러스터에 제출된 작업 요구 사항을 충족하기 위해 추가 클라우드 서비스를 생성 및 사용할 수 있습니다.

노드 서버 구성 요소

Kubernetes에서 컨테이너를 실행하여 작업을 수행하는 서버를 노드라고 합니다. 노드 서버에는 마스터 구성 요소와 통신하고, 컨테이너 네트워킹을 구성하고, 할당된 실제 워크로드를 실행하는 데 필요한 몇 가지 요구 사항이 있습니다.

컨테이너 런타임

각 노드에 있어야 하는 첫 번째 구성 요소는 컨테이너 런타임입니다. 일반적으로 runc를 설치하고 실행하면 이 요구 사항이 충족됩니다.

컨테이너 런타임은 상대적으로 고립되어 있지만 가벼운 운영 환경에 캡슐화된 애플리케이션인 컨테이너를 시작하고 관리하는 일을 담당합니다. 클러스터의 각 작업 단위는 기본 수준에서 배포해야 하는 하나 이상의 컨테이너로 구현됩니다. 각 노드의 컨테이너 런타임은 클러스터에 제출된 워크로드에 정의된 컨테이너를 최종적으로 실행하는 구성 요소입니다.

큐벨렛

클러스터 그룹이 있는 각 노드의 주요 접점은 kubelet이라는 작은 서비스입니다. 이 서비스는 컨트롤 플레인 서비스와 정보를 주고받고 etcd 저장소와 상호 작용하여 구성 세부 정보를 읽거나 새 값을 쓰는 일을 담당합니다.

kubelet 서비스는 마스터 구성 요소와 통신하여 클러스터에 인증하고 명령과 작업을 수신합니다. 작업은 워크로드 및 작동 매개변수를 정의하는 매니페스트 형식으로 수신됩니다. 그런 다음 kubelet 프로세스는 노드 서버에서 작업 상태를 유지하는 책임을 맡습니다. 필요에 따라 컨테이너를 실행하거나 제거하도록 컨테이너 런타임을 제어합니다.

큐브 프록시

개별 호스트 서브넷을 관리하고 다른 구성 요소에서 서비스를 사용할 수 있도록 하기 위해 kube-proxy라는 작은 프록시 서비스가 각 노드 서버에서 실행됩니다. 이 프로세스는 요청을 올바른 컨테이너로 전달하고 기본 로드 밸런싱을 수행할 수 있으며 일반적으로 네트워킹 환경이 예측 가능하고 액세스 가능하지만 적절한 경우 격리되도록 하는 역할을 합니다.

Kubernetes 객체 및 워크로드

컨테이너는 애플리케이션을 배포하는 데 사용되는 기본 메커니즘이지만 Kubernetes는 컨테이너 인터페이스에 대한 추가 추상화 계층을 사용하여 확장성, 복원력 및 수명 주기 관리 기능을 제공합니다. 컨테이너를 직접 관리하는 대신 사용자는 Kubernetes 개체 모델에서 제공하는 다양한 기본 요소로 구성된 인스턴스를 정의하고 상호 작용합니다. 아래에서 이러한 워크로드를 정의하는 데 사용할 수 있는 다양한 유형의 개체를 살펴보겠습니다.

포드

Pod는 Kubernetes가 다루는 가장 기본적인 단위입니다. 컨테이너 자체는 호스트에 할당되지 않습니다. 대신 하나 이상의 긴밀하게 결합된 컨테이너가 포드라는 개체에 캡슐화됩니다.

포드는 일반적으로 단일 애플리케이션으로 제어되어야 하는 하나 이상의 컨테이너를 나타냅니다. Pod는 밀접하게 함께 작동하고 수명 주기를 공유하며 항상 동일한 노드에서 예약되어야 하는 컨테이너로 구성됩니다. 이들은 완전히 하나의 단위로 관리되며 환경, 볼륨 및 IP 공간을 공유합니다. 컨테이너화된 구현에도 불구하고 일반적으로 클러스터가 포드의 리소스 및 예약을 관리하는 방법을 가장 잘 개념화하려면 포드를 단일 모놀리식 애플리케이션으로 생각해야 합니다.

일반적으로 포드는 워크로드의 일반적인 목적을 충족하는 기본 컨테이너와 선택적으로 밀접하게 관련된 작업을 용이하게 하는 일부 도우미 컨테이너로 구성됩니다. 이러한 프로그램은 자체 컨테이너에서 실행 및 관리되는 이점이 있지만 기본 애플리케이션에 밀접하게 연결되어 있습니다. 예를 들어 포드에는 기본 애플리케이션 서버를 실행하는 하나의 컨테이너와 외부 리포지토리에서 변경 사항이 감지될 때 파일을 공유 파일 시스템으로 풀다운하는 도우미 컨테이너가 있을 수 있습니다. 작업에 더 적합한 다른 상위 수준 개체가 있기 때문에 포드 수준에서는 일반적으로 수평 확장이 권장되지 않습니다.

일반적으로 사용자는 포드가 애플리케이션에 일반적으로 필요한 일부 기능(예: 정교한 수명 주기 관리 및 확장)을 제공하지 않기 때문에 포드를 직접 관리해서는 안 됩니다. 대신 사용자는 포드 또는 포드 템플릿을 기본 구성 요소로 사용하지만 추가 기능을 구현하는 상위 수준 개체로 작업하는 것이 좋습니다.

복제 컨트롤러 및 복제 세트

종종 Kubernetes로 작업할 때 단일 포드로 작업하는 대신 동일한 복제된 포드 그룹을 대신 관리하게 됩니다. 이들은 포드 템플릿에서 생성되며 복제 컨트롤러 및 복제 세트로 알려진 컨트롤러에 의해 수평으로 확장될 수 있습니다.

복제 컨트롤러는 실행 중인 복사본의 수를 늘리거나 줄여 포드의 동일한 복제본을 수평으로 확장하기 위해 포드 템플릿 및 제어 매개 변수를 정의하는 개체입니다. 이는 Kubernetes 내에서 기본적으로 부하를 분산하고 가용성을 높이는 쉬운 방법입니다. 복제 컨트롤러는 포드 정의와 매우 유사한 템플릿이 복제 컨트롤러 구성 내에 내장되어 있기 때문에 필요에 따라 새 포드를 생성하는 방법을 알고 있습니다.

복제 컨트롤러는 클러스터에 배포된 포드 수가 해당 구성의 포드 수와 일치하는지 확인하는 역할을 합니다. 포드 또는 기본 호스트에 장애가 발생하면 컨트롤러가 보상을 위해 새 포드를 시작합니다. 컨트롤러 구성의 복제본 수가 변경되면 컨트롤러는 원하는 수와 일치하도록 컨테이너를 시작하거나 종료합니다. 복제 컨트롤러는 롤링 업데이트를 수행하여 Pod 집합을 하나씩 새 버전으로 롤오버하여 애플리케이션 가용성에 미치는 영향을 최소화할 수도 있습니다.

복제 세트는 컨트롤러가 관리할 팟(Pod)을 식별하는 방법에서 더 큰 유연성을 가진 복제 컨트롤러 설계의 반복입니다. 복제 세트는 더 큰 복제본 선택 기능으로 인해 복제 컨트롤러를 대체하기 시작했지만 복제 컨트롤러처럼 백엔드를 새 버전으로 순환시키는 롤링 업데이트를 수행할 수 없습니다. 대신, 복제 세트는 해당 기능을 제공하는 추가 상위 레벨 장치 내부에서 사용하기 위한 것입니다.

포드와 마찬가지로 복제 컨트롤러와 복제 세트는 모두 직접 작업하는 단위가 아닙니다. 수평 확장 및 안정성 보장을 추가하기 위해 팟(Pod) 디자인을 기반으로 구축되지만 더 복잡한 개체에서 볼 수 있는 세분화된 수명 주기 관리 기능이 부족합니다.

배포

배포는 직접 만들고 관리하는 가장 일반적인 워크로드 중 하나입니다. 배포는 복제 세트를 빌딩 블록으로 사용하여 유연한 수명 주기 관리 기능을 믹스에 추가합니다.

복제 세트로 구축된 배포는 복제 컨트롤러가 제공하는 기능을 복제하는 것처럼 보일 수 있지만 배포는 롤링 업데이트 구현에 존재하는 많은 문제점을 해결합니다. 복제 컨트롤러로 애플리케이션을 업데이트할 때 사용자는 현재 컨트롤러를 대체할 새 복제 컨트롤러에 대한 계획을 제출해야 합니다. 복제 컨트롤러를 사용할 때 이력 추적, 업데이트 중 네트워크 장애 복구, 잘못된 변경 사항 롤백과 같은 작업은 어렵거나 사용자의 책임으로 남겨집니다.

배포는 복제된 포드의 수명 주기 관리를 용이하게 하도록 설계된 상위 수준 개체입니다. 구성을 변경하여 배포를 쉽게 수정할 수 있으며 Kubernetes는 복제 세트를 조정하고, 서로 다른 애플리케이션 버전 간의 전환을 관리하고, 선택적으로 이벤트 기록을 유지하고 기능을 자동으로 실행 취소합니다. 이러한 기능으로 인해 배포는 가장 자주 작업하는 Kubernetes 개체 유형이 될 수 있습니다.

상태 저장 세트

상태 저장 세트는 주문 및 고유성을 보장하는 특수 포드 컨트롤러입니다. 주로 배포 순서 지정, 영구 데이터 또는 안정적인 네트워킹과 관련된 특별한 요구 사항이 있을 때 더 세밀하게 제어하는 데 사용됩니다. 예를 들어 상태 저장 세트는 새 노드로 일정이 변경되더라도 동일한 볼륨에 액세스해야 하는 데이터베이스와 같은 데이터 지향 애플리케이션과 연결되는 경우가 많습니다.

상태 저장 세트는 포드를 다른 노드로 이동해야 하는 경우에도 지속되는 각 포드에 고유한 숫자 기반 이름을 생성하여 안정적인 네트워킹 식별자를 제공합니다. 마찬가지로 일정 변경이 필요한 경우 영구 스토리지 볼륨을 포드와 함께 전송할 수 있습니다. 우발적인 데이터 손실을 방지하기 위해 포드가 삭제된 후에도 볼륨이 유지됩니다.

확장을 배포하거나 조정할 때 상태 저장 세트는 이름의 번호가 매겨진 식별자에 따라 작업을 수행합니다. 이것은 실행 순서에 대한 더 큰 예측 가능성과 제어를 제공하며, 이는 경우에 따라 유용할 수 있습니다.

데몬 세트

데몬 세트는 클러스터의 각 노드(또는 지정된 경우 하위 집합)에서 포드 사본을 실행하는 또 다른 특수 형태의 포드 컨트롤러입니다. 이것은 유지 관리를 수행하고 노드 자체에 서비스를 제공하는 데 도움이 되는 포드를 배포할 때 가장 자주 유용합니다.

예를 들어 로그 수집 및 전달, 메트릭 집계, 노드 자체의 기능을 향상시키는 서비스 실행은 데몬 세트의 인기 있는 후보입니다. 데몬 세트는 종종 기본 서비스를 제공하고 플릿 전체에서 필요하기 때문에 다른 컨트롤러가 특정 호스트에 포드를 할당하지 못하도록 하는 포드 일정 제한을 우회할 수 있습니다. 예를 들어, 고유한 책임으로 인해 마스터 서버는 일반 포드 스케줄링에 사용할 수 없도록 자주 구성되지만 데몬 세트는 필수 서비스가 실행되고 있는지 확인하기 위해 포드별로 제한을 무시할 수 있는 기능이 있습니다.

작업 및 Cron 작업

지금까지 설명한 워크로드는 모두 장기 실행되는 서비스와 같은 수명 주기를 가정했습니다. Kubernetes는 작업이라는 워크로드를 사용하여 실행 중인 컨테이너가 작업을 완료한 후 일정 시간이 지나면 성공적으로 종료될 것으로 예상되는 작업 기반 워크플로를 제공합니다. 지속적인 서비스를 실행하는 대신 일회성 또는 일괄 처리를 수행해야 하는 경우 작업이 유용합니다.

작업 기반 구축은 cron 작업입니다. 일정에 따라 스크립트를 실행하는 Linux 및 Unix 계열 시스템의 기존 cron 데몬과 마찬가지로 Kubernetes의 cron 작업은 일정 구성 요소로 작업을 실행할 수 있는 인터페이스를 제공합니다. 크론 작업은 미래에 또는 정기적으로 반복해서 실행할 작업을 예약하는 데 사용할 수 있습니다. Kubernetes 크론 작업은 기본적으로 단일 운영 체제 대신 클러스터를 플랫폼으로 사용하여 클래식 크론 동작을 다시 구현한 것입니다.

기타 Kubernetes 구성요소

클러스터에서 실행할 수 있는 워크로드 외에도 Kubernetes는 애플리케이션을 관리하고, 네트워킹을 제어하고, 지속성을 활성화하는 데 도움이 되는 다양한 추상화를 제공합니다. 여기서는 좀 더 일반적인 몇 가지 예에 대해 논의할 것입니다.

서비스

지금까지 우리는 "서비스\라는 용어를 전통적인 유닉스와 같은 의미로 사용했습니다. 요청에 응답할 수 있는, 종종 네트워크에 연결된 장기 실행 프로세스를 나타냅니다. 그러나 쿠버네티스에서 서비스는 다음과 같은 구성 요소입니다. 기본 내부 로드 밸런서 및 포드 대사 역할 서비스는 동일한 기능을 수행하는 포드의 논리적 컬렉션을 함께 그룹화하여 단일 엔터티로 표시합니다.

이를 통해 특정 유형의 모든 백엔드 컨테이너를 추적하고 라우팅할 수 있는 서비스를 배포할 수 있습니다. 내부 소비자는 서비스에서 제공하는 안정적인 엔드포인트에 대해서만 알면 됩니다. 한편, 서비스 추상화를 통해 필요에 따라 백엔드 작업 단위를 확장하거나 교체할 수 있습니다. 서비스의 IP 주소는 라우팅 대상 포드의 변경 사항에 관계없이 안정적으로 유지됩니다. 서비스를 배포하면 검색 가능성을 쉽게 얻고 컨테이너 설계를 간소화할 수 있습니다.

하나 이상의 포드에 대한 액세스를 다른 애플리케이션이나 외부 소비자에게 제공해야 할 때마다 서비스를 구성해야 합니다. 예를 들어 인터넷에서 액세스할 수 있어야 하는 웹 서버를 실행하는 포드 세트가 있는 경우 서비스가 필요한 추상화를 제공합니다. 마찬가지로 웹 서버가 데이터를 저장하고 검색해야 하는 경우 데이터베이스 포드에 대한 액세스 권한을 부여하도록 내부 서비스를 구성할 수 있습니다.

기본적으로 서비스는 내부적으로 라우팅 가능한 IP 주소를 통해서만 사용할 수 있지만 여러 전략 중 하나를 선택하여 클러스터 외부에서 사용할 수 있습니다. NodePort 구성은 각 노드의 외부 네트워킹 인터페이스에서 정적 포트를 여는 방식으로 작동합니다. 외부 포트에 대한 트래픽은 내부 클러스터 IP 서비스를 사용하여 적절한 포드로 자동 라우팅됩니다.

또는 LoadBalancer 서비스 유형은 클라우드 공급자의 Kubernetes 로드 밸런서 통합을 사용하여 서비스로 라우팅할 외부 로드 밸런서를 생성합니다. 클라우드 컨트롤러 관리자는 적절한 리소스를 생성하고 내부 서비스 서비스 주소를 사용하여 구성합니다.

볼륨 및 영구 볼륨

안정적으로 데이터를 공유하고 컨테이너 재시작 사이의 가용성을 보장하는 것은 많은 컨테이너화된 환경에서 어려운 과제입니다. 컨테이너 런타임은 종종 컨테이너의 수명을 넘어 지속되는 컨테이너에 스토리지를 연결하는 일부 메커니즘을 제공하지만 일반적으로 구현에는 유연성이 부족합니다.

이 문제를 해결하기 위해 Kubernetes는 Pod 내의 모든 컨테이너에서 데이터를 공유하고 Pod가 종료될 때까지 사용 가능한 상태를 유지하도록 허용하는 자체 볼륨 추상화를 사용합니다. 이는 긴밀하게 결합된 파드가 복잡한 외부 메커니즘 없이 파일을 쉽게 공유할 수 있음을 의미합니다. 포드 내의 컨테이너 오류는 공유 파일에 대한 액세스에 영향을 미치지 않습니다. 포드가 종료되면 공유 볼륨이 파괴되므로 진정한 영구 데이터에는 좋은 솔루션이 아닙니다.

영구 볼륨은 Pod 수명 주기에 연결되지 않은 보다 강력한 스토리지를 추상화하기 위한 메커니즘입니다. 대신 관리자는 사용자가 실행 중인 팟(Pod)에 대해 요청 및 청구할 수 있는 클러스터의 스토리지 리소스를 구성할 수 있습니다. 포드가 영구 볼륨으로 완료되면 볼륨의 회수 정책에 따라 수동으로 삭제하거나 데이터와 함께 즉시 제거할 때까지 볼륨을 유지할지 여부가 결정됩니다. 영구 데이터는 노드 기반 오류를 방지하고 로컬에서 사용 가능한 것보다 더 많은 양의 스토리지를 할당하는 데 사용할 수 있습니다.

레이블 및 주석

Kubernetes 조직의 추상화는 레이블 지정과 관련되지만 다른 개념과는 다릅니다. Kubernetes의 레이블은 Kubernetes 개체에 연결하여 그룹의 일부로 표시할 수 있는 시맨틱 태그입니다. 그런 다음 관리 또는 라우팅을 위해 다른 인스턴스를 대상으로 지정할 때 이를 선택할 수 있습니다. 예를 들어 각 컨트롤러 기반 개체는 레이블을 사용하여 작동해야 하는 포드를 식별합니다. 서비스는 레이블을 사용하여 요청을 라우팅해야 하는 백엔드 포드를 이해합니다.

레이블은 간단한 키-값 쌍으로 제공됩니다. 각 단위는 둘 이상의 레이블을 가질 수 있지만 각 단위는 각 키에 대해 하나의 항목만 가질 수 있습니다. 일반적으로 "name\ 키는 범용 식별자로 사용되지만 개발 단계, 공개 접근성, 애플리케이션 버전 등과 같은 다른 기준으로 개체를 추가로 분류할 수 있습니다.

주석은 객체에 임의의 키-값 정보를 첨부할 수 있는 유사한 메커니즘입니다. 팟(Pod)을 선택 기준과 일치시키는 데 유용한 시맨틱 정보에 레이블을 사용해야 하지만 주석은 보다 자유로운 형식이며 덜 구조화된 데이터를 포함할 수 있습니다. 일반적으로 주석은 선택 목적에 도움이 되지 않는 개체에 풍부한 메타데이터를 추가하는 방법입니다.

결론

Kubernetes는 사용자가 고도로 추상화된 플랫폼에서 확장 가능하고 가용성이 높은 컨테이너화된 워크로드를 실행할 수 있게 해주는 흥미로운 프로젝트입니다. 쿠버네티스의 아키텍처와 내부 구성 요소 집합은 처음에는 어려워 보일 수 있지만 그 힘, 유연성 및 강력한 기능 집합은 오픈 소스 세계에서 타의 추종을 불허합니다. 기본 빌딩 블록이 어떻게 결합되는지 이해하면 플랫폼의 기능을 최대한 활용하여 워크로드를 대규모로 실행하고 관리하는 시스템 설계를 시작할 수 있습니다.