소개
Kubernetes는 클러스터 환경에서 컨테이너화된 애플리케이션을 관리하기 위해 Google에서 초기에 개발되었고 Cloud Native Computing Foundation (CNCF)에서 지원하는 강력한 오픈 소스 시스템입니다. 이는 관련된 분산 구성 요소 및 서비스를 다양한 인프라에서 관리하는 더 나은 방법을 제공하기 위해 목표로 합니다. Kubernetes에 대해 더 알아보려면 아래 가이드를 살펴보세요. 만약 관리형 Kubernetes 호스팅 서비스를 찾고 있다면, 성장을 위해 구축된 간편한 관리형 Kubernetes 서비스를 확인하세요.
이 가이드에서는 Kubernetes가 무엇인지, Kubernetes의 기본 개념 중 일부에 대해 논의할 것입니다. 시스템의 아키텍처, 해결하는 문제 및 컨테이너화된 배포 및 스케일링을 처리하는 모델에 대해 알아보겠습니다.
Kubernetes란?
Kubernetes는 기본 수준에서 컨테이너화된 애플리케이션을 클러스터에서 실행하고 조정하는 시스템입니다. 이는 컨테이너화된 애플리케이션 및 서비스의 라이프사이클을 완전히 관리하는 플랫폼으로, 예측 가능성, 확장 가능성 및 고가용성을 제공하는 방법을 사용합니다.
쿠버네티스 사용자로서, 애플리케이션이 어떻게 실행되고 다른 애플리케이션 또는 외부와 상호 작용할 수 있는지 정의할 수 있습니다. 서비스를 확장하거나 축소하고, 우아한 롤링 업데이트를 수행하고, 애플리케이션의 다른 버전 간에 트래픽을 전환하여 기능을 테스트하거나 문제가 있는 배포를 롤백할 수 있습니다. 쿠버네티스는 고도로 유연하고 강력하며 신뢰성 높은 방식으로 애플리케이션을 정의하고 관리할 수 있도록 인터페이스와 구성 가능한 플랫폼 기본 요소를 제공합니다.
쿠버네티스 아키텍처
이러한 기능을 제공하는 방법을 이해하려면, 쿠버네티스가 어떻게 설계되고 조직되어 있는지 전반적으로 파악하는 것이 도움이 됩니다. 쿠버네티스는 각 레이어에서 발견되는 복잡성을 추상화하는 각기 다른 레이어로 구성된 시스템으로 시각화할 수 있습니다.
기본적으로 쿠버네티스는 공유 네트워크를 사용하여 개별 물리적 또는 가상 머신을 클러스터로 결합합니다. 이 쿠버네티스 클러스터는 모든 쿠버네티스 구성 요소, 기능 및 워크로드가 구성된 물리적 플랫폼입니다.
Kubernetes 클러스터의 기계들은 각각 Kubernetes 생태계 내에서 역할을 부여받습니다. 하나의 서버(또는 고가용성 배포에서 소규모 그룹)가 마스터 서버로 작동합니다. 이 서버는 클러스터를 위한 게이트웨이이자 두뇌 역할을 하며 사용자와 클라이언트에게 Kubernetes API를 노출시켜 다른 서버를 건강 상태로 확인하고 작업을 분할하고 할당하는 가장 좋은 방법을 결정(일반적으로 “스케줄링”으로 알려짐)하고 다른 구성 요소 간의 통신을 조정합니다(때로는 컨테이너 오케스트레이션으로 언급됨). 마스터 서버는 클러스터와의 주요 연락처 역할을 하며 Kubernetes가 제공하는 대부분의 중앙 집중식 논리를 담당합니다.
클러스터의 다른 기계들은 노드로 지정됩니다: 로컬 및 외부 리소스를 사용하여 작업을 수락하고 실행하는 서버들입니다. 격리, 관리 및 유연성을 돕기 위해 Kubernetes는 애플리케이션 및 서비스를 컨테이너로 실행하므로 각 노드는 컨테이너 실행 환경(Docker 또는 rkt와 같은)이 필요합니다. 노드는 마스터 서버로부터 작업 지시를 받고 이에 따라 컨테이너를 생성하거나 제거하며, 네트워크 규칙을 조정하여 트래픽을 적절하게 라우팅하고 전달합니다.
위에서 언급한대로 응용 프로그램 및 서비스 자체는 컨테이너 내에서 클러스터에서 실행됩니다. 기본 구성 요소는 응용 프로그램의 원하는 상태가 클러스터의 실제 상태와 일치하는지 확인합니다. 사용자는 주요 Kubernetes API 서버와 직접 또는 클라이언트 및 라이브러리를 통해 클러스터와 상호 작용합니다. 응용 프로그램이나 서비스를 시작하려면 JSON 또는 YAML로 선언적 계획이 제출되어 무엇을 생성하고 어떻게 관리해야 하는지 정의됩니다. 그런 다음 마스터 서버는 계획을 받아들이고 요구 사항 및 시스템의 현재 상태를 조사하여 해당 인프라에서 실행하는 방법을 결정합니다. 지정된 계획에 따라 실행되는 사용자 정의 응용 프로그램 그룹은 Kubernetes의 최종 계층을 나타냅니다.
마스터 서버 구성 요소
위에서 설명한대로 마스터 서버는 Kubernetes 클러스터의 주요 제어 평면으로 작동합니다. 관리자 및 사용자의 주요 연락처로 작동하며 비교적 미숙한 워커 노드를 위해 많은 클러스터 전체 시스템을 제공합니다. 전반적으로 마스터 서버의 구성 요소는 사용자 요청을 수락하고 워크로드 컨테이너를 예약하는 가장 좋은 방법을 결정하며 클라이언트 및 노드를 인증하고 클러스터 전체 네트워킹을 조정하며 스케일링 및 건강 확인 책임을 관리합니다.
이러한 구성 요소는 단일 머신 또는 여러 서버에 분산하여 설치할 수 있습니다. 이 섹션에서는 Kubernetes 클러스터의 마스터 서버에 연관된 각 개별 구성 요소를 살펴볼 것입니다.
etcd
Kubernetes가 작동하는 데 필요한 기본 구성 요소 중 하나는 전역적으로 사용 가능한 구성 저장소입니다. etcd 프로젝트는 CoreOS (운영 체제) 팀에서 개발한 경량 분산형 키-값 저장소로, 여러 노드에 걸쳐 구성할 수 있습니다.
Kubernetes는 클러스터의 각 노드에서 액세스할 수 있는 구성 데이터를 저장하기 위해 etcd를 사용합니다. 이를 서비스 검색에 사용할 수 있으며, 구성 요소가 최신 정보에 따라 자신을 구성하거나 다시 구성하는 데 도움이 됩니다. 또한 리더 선출 및 분산 락잉과 같은 클러스터 상태를 유지하는 데 도움이 됩니다. 간단한 HTTP/JSON API를 제공함으로써 값을 설정하거나 검색하는 인터페이스가 매우 직관적입니다.
제어 평면의 대부분 다른 구성 요소와 마찬가지로 etcd는 단일 마스터 서버에 구성하거나 프로덕션 시나리오에서 여러 기계에 분산하여 구성할 수 있습니다. 유일한 요구 사항은 각 Kubernetes 머신에서 네트워크에 액세스할 수 있어야 합니다.
kube-apiserver
가장 중요한 마스터 서비스 중 하나는 API 서버입니다. 이는 사용자가 Kubernetes의 작업 부하 및 조직 단위를 구성할 수 있도록 하는 전체 클러스터의 주요 관리 지점입니다. 또한 배포된 컨테이너의 서비스 세부 정보가 etcd 저장소와 일치하는지 확인하는 것이 책임입니다. 이는 클러스터의 건강 상태를 유지하고 정보 및 명령을 전파하기 위한 다양한 구성 요소 사이의 다리 역할을 합니다.
API 서버는 RESTful 인터페이스를 구현합니다. 이는 많은 다양한 도구와 라이브러리가 쉽게 통신할 수 있음을 의미합니다. 로컬 컴퓨터에서 Kubernetes 클러스터와 상호 작용하는 기본 방법으로 kubectl이라는 클라이언트가 제공됩니다.
kube-controller-manager
컨트롤러 매니저는 다양한 책임을 갖는 일반 서비스입니다. 주로 클러스터의 상태를 조절하고 작업 부하의 라이프 사이클을 관리하며 루틴 작업을 수행하는 다양한 컨트롤러를 관리합니다. 예를 들어, 복제 컨트롤러는 팟에 정의된 복제본(동일한 복사본)의 수가 현재 클러스터에 배포된 수와 일치하도록 보장합니다. 이러한 작업의 세부 정보는 etcd에 작성되며, 컨트롤러 매니저는 API 서버를 통해 변경 사항을 감시합니다.
변화가 발생하면 컨트롤러가 새로운 정보를 읽고 원하는 상태를 충족하는 절차를 실행합니다. 이는 응용 프로그램의 확장 또는 축소, 엔드포인트 조정 등을 포함할 수 있습니다.
kube-scheduler
클러스터에서 특정 노드에 작업 부하를 할당하는 실제 과정은 스케줄러입니다. 이 서비스는 작업 부하의 운영 요구 사항을 읽어들이고 현재 인프라 환경을 분석하여 작업을 수용 가능한 노드에 배치합니다.
스케줄러는 각 호스트의 사용 가능한 용량을 추적하여 작업 부하가 사용 가능한 리소스를 초과하여 예약되지 않도록 합니다. 스케줄러는 각 서버의 총 용량과 이미 할당된 리소스를 알아야 합니다.
cloud-controller-manager
쿠버네티스는 다양한 환경에서 배포될 수 있으며 클러스터의 리소스 상태를 이해하고 관리하기 위해 다양한 인프라 제공업체와 상호 작용할 수 있습니다. 쿠버네티스는 연결 가능한 저장소 및 로드 밸런서와 같은 리소스의 일반적인 표현과 함께 작동하지만, 비동질적인 클라우드 제공업체에서 제공되는 실제 리소스와의 매핑 방법이 필요합니다.
클라우드 컨트롤러 매니저는 쿠버네티스가 다양한 기능, 특징 및 API를 갖는 제공 업체와 상호 작용할 수 있도록 하는 ‘접착제’ 역할을 합니다. 이는 쿠버네티스가 내부적으로 비교적 일반적인 구조를 유지하면서 클라우드 제공 업체로부터 수집된 정보에 따라 상태 정보를 업데이트하고, 시스템에서 필요에 따라 클라우드 리소스를 조정하고, 클러스터에 제출된 작업 요구 사항을 충족시키기 위해 추가 클라우드 서비스를 생성하고 사용할 수 있게 합니다.
노드 서버 구성 요소
쿠버네티스에서 컨테이너를 실행하여 작업을 수행하는 서버를 노드라고 합니다. 노드 서버는 마스터 구성 요소와 통신하고, 컨테이너 네트워킹을 구성하며, 할당된 실제 작업을 실행하기 위해 필요한 몇 가지 요구 사항이 있습니다.
A Container Runtime
각 노드가 가져야 하는 첫 번째 구성 요소는 컨테이너 런타임입니다. 일반적으로 이 요구 사항은 Docker를 설치하고 실행함으로써 충족되지만, rkt 및 runc와 같은 대안도 사용할 수 있습니다.
컨테이너 런타임은 상대적으로 격리된 경량 운영 환경에서 캡슐화된 응용 프로그램을 시작하고 관리하는 역할을 합니다. 클러스터의 각 작업 단위는 기본 수준에서 하나 이상의 컨테이너로 구현되어야 합니다. 각 노드의 컨테이너 런타임은 클러스터로 제출된 작업 부하에서 정의된 컨테이너를 실행하는 최종 구성 요소입니다.
kubelet
각 노드와 클러스터 그룹 간의 주요 연락 점은 kubelet이라는 작은 서비스입니다. 이 서비스는 제어 평면 서비스와의 정보를 중계하고, etcd 저장소와 상호 작용하여 구성 세부 정보를 읽거나 새 값으로 쓰는 역할을 합니다.
kubelet 서비스는 마스터 구성 요소와 통신하여 클러스터에 인증하고 명령 및 작업을 받습니다. 작업은 작업 부하와 작업 매개변수를 정의하는 매니페스트 형식으로 수신됩니다. 그런 다음 kubelet 프로세스는 노드 서버에서 작업의 상태를 유지하는 책임을 맡습니다. 필요에 따라 컨테이너 런타임을 제어하여 컨테이너를 시작하거나 파괴합니다.
kube-proxy
개별 호스트 서브넷 관리 및 다른 구성 요소에 서비스를 제공하기 위해 각 노드 서버에서 kube-proxy라는 작은 프록시 서비스가 실행됩니다. 이 프로세스는 요청을 올바른 컨테이너로 전달하고 원시적인 로드 밸런싱을 수행하며 일반적으로 네트워킹 환경이 예측 가능하고 접근 가능하며 필요한 경우 격리될 수 있도록 보장합니다.
쿠버네티스 객체 및 워크로드
컨테이너는 컨테이너화된 응용 프로그램을 배포하는 데 사용되는 기본 메커니즘이지만, 쿠버네티스는 컨테이너 인터페이스 위에 추가로 추상화 계층을 사용하여 확장, 내결함성 및 라이프사이클 관리 기능을 제공합니다. 사용자는 컨테이너를 직접 관리하는 대신 쿠버네티스 객체 모델에서 제공하는 다양한 기본 요소로 구성된 인스턴스를 정의하고 상호 작용합니다. 아래에서 이러한 워크로드를 정의하는 데 사용할 수 있는 다양한 유형의 객체를 살펴보겠습니다.
Pods
A pod is the most basic unit that Kubernetes deals with. Containers themselves are not assigned to hosts. Instead, one or more tightly coupled containers are encapsulated in an object called a pod.
A pod generally represents containers that should be controlled as a single application. Pods consist of containers that operate closely together, share a life cycle, and should always be scheduled on the same node. They are managed entirely as a unit and share their environment, volumes, and IP space. In spite of their containerized implementation, you should generally think of pods as a single, monolithic application to best conceptualize how the cluster will manage the pod’s resources and scheduling.
일반적으로, 팟은 주요 워크로드 목적을 충족시키는 주요 컨테이너와 선택적으로 관련 작업을 촉진하는 몇 가지 도우미 컨테이너로 구성됩니다. 이들은 자체 컨테이너에서 실행되고 관리되는 것이 유익하지만 주요 응용 프로그램과 긴밀하게 연결된 프로그램입니다. 예를 들어, 팟은 기본 응용 프로그램 서버를 실행하는 하나의 컨테이너와 외부 리포지토리에서 변경 사항이 감지될 때 공유 파일 시스템에 파일을 내려받는 도우미 컨테이너가 있을 수 있습니다. 팟 수평 확장은 일반적으로 다른 더 적합한 고수준 개체가 있기 때문에 팟 수준에서 권장되지 않습니다.
일반적으로 사용자는 스스로 팟을 관리하지 않아야 합니다. 왜냐하면 애플리케이션에서 typ필Typically ical life cycle management과 확장이 필요한 일부 기능을 제공하지 않기 때문입니다. 대신, 사용자는 팟 또는 팟 템플릿을 기본 구성 요소로 사용하지만 추가 기능을 구현하는 고수준 개체와 함께 작업하도록 권장됩니다.
복제 컨트롤러 및 복제 세트
일반적으로 Kubernetes를 사용할 때, 단일 팟을 처리하는 대신 동일한 복제된 팟 그룹을 관리하게 됩니다. 이들은 팟 템플릿에서 생성되며 복제 컨트롤러 및 복제 세트라고하는 컨트롤러에 의해 수평으로 확장될 수 있습니다.
A replication controller is an object that defines a pod template and control parameters to scale identical replicas of a pod horizontally by increasing or decreasing the number of running copies. This is an easy way to distribute load and increase availability natively within Kubernetes. The replication controller knows how to create new pods as needed because a template that closely resembles a pod definition is embedded within the replication controller configuration.
복제 컨트롤러는 클러스터에 배포된 팟의 수가 구성에 지정된 팟 수와 일치하도록 보장하는 역할을 담당합니다. 팟이나 하부 호스트가 실패하면 컨트롤러가 보상하기 위해 새로운 팟을 시작합니다. 컨트롤러 구성의 복제본 수가 변경되면 컨트롤러가 원하는 수와 일치하도록 컨테이너를 시작하거나 종료합니다. 복제 컨트롤러는 또한 애플리케이션 가용성에 미치는 영향을 최소화하기 위해 한 번에 한 버전씩 일련의 팟을 새 버전으로 전환하는 롤링 업데이트를 수행할 수 있습니다.
복제 세트는 복제 컨트롤러 설계의 반복으로, 컨트롤러가 관리해야 하는 팟을 식별하는 방법에 대한 더 큰 유연성을 가지고 있습니다. 복제 세트는 복제 컨트롤러처럼 새 버전으로 백엔드를 사이클링하는 롤링 업데이트를 수행할 수 없지만, 더 큰 복제 선택 기능을 제공하기 때문에 복제 컨트롤러를 대체하기 시작했습니다. 대신, 복제 세트는 해당 기능을 제공하는 추가적이고 상위 수준의 단위 내부에서 사용하기 위해 설계되었습니다.
팟과 마찬가지로, 복제 컨트롤러와 복제 세트 모두 직접 작업할 가능성이 거의 없는 단위입니다. 수평 스케일링과 신뢰성 보장을 추가하기 위해 팟 디자인을 기반으로 하지만, 더 복잡한 객체에서 발견되는 일부 세부 수명 주기 관리 기능이 부족합니다.
배포
배포는 직접 생성하고 관리하는 가장 일반적인 작업 중 하나입니다. 배포는 복제 세트를 구성 요소로 사용하여 미세한 수명주기 관리 기능을 추가합니다.
복제 세트로 구축된 배포는 복제 컨트롤러에서 제공되는 기능을 중복된 것으로 보일 수 있지만, 배포는 롤링 업데이트의 구현에서 존재했던 많은 고통 요소를 해결합니다. 복제 컨트롤러로 응용 프로그램을 업데이트할 때 사용자는 현재 컨트롤러를 대체할 새로운 복제 컨트롤러에 대한 계획을 제출해야 합니다. 복제 컨트롤러를 사용할 때는 히스토리 추적, 업데이트 중 네트워크 장애에서의 복구, 잘못된 변경 내용 롤백 등의 작업이 어렵거나 사용자의 책임으로 남게 됩니다.
배포는 복제된 팟의 수명주기 관리를 용이하게하기 위해 고안된 고수준 객체입니다. 구성을 변경함으로써 배포를 쉽게 수정할 수 있으며, Kubernetes는 레플리카 세트를 조정하고 서로 다른 애플리케이션 버전 간의 전환을 관리하며, 선택적으로 이벤트 기록 및 자동으로 되돌릴 수 있는 기능을 유지보수합니다. 이러한 기능으로 인해 배포가 여러분이 가장 자주 작업할 Kubernetes 객체 유형이 될 것으로 예상됩니다.
Stateful Sets
Stateful sets는 순서와 고유성을 보장하는 특수한 파드 컨트롤러입니다. 주로 배포 순서, 지속적인 데이터 또는 안정적인 네트워킹과 관련된 특별한 요구 사항이 있는 경우 더 세분화된 제어를 제공하기 위해 사용됩니다. 예를 들어, 상태 세트는 데이터 중심 응용 프로그램인 데이터베이스와 같이, 새로운 노드로 재스케줄되어도 동일한 볼륨에 액세스해야 하는 경우에 자주 사용됩니다.
상태 세트는 각 파드에 대해 고유한 번호 기반 이름을 생성하여 안정적인 네트워킹 식별자를 제공합니다. 이는 필요한 경우 파드를 다른 노드로 이동해도 유지됩니다. 마찬가지로, 스케줄링이 필요한 경우에도 영구 저장 볼륨을 파드와 전송할 수 있습니다. 볼륨은 실수로 데이터 손실을 방지하기 위해 파드가 삭제된 후에도 지속됩니다.
배포 또는 스케일 조정 시 상태 세트는 이름의 번호 식별자에 따라 작업을 수행합니다. 이는 실행 순서에 대한 더 큰 예측 가능성과 제어를 제공하여 일부 경우에 유용합니다.
데몬 세트
데몬 세트는 클러스터의 각 노드에 파드의 사본을 실행하는 또 다른 특수한 형태의 파드 컨트롤러입니다 (지정된 경우 하위 집합). 이것은 주로 쿠버네티스 노드 자체를 위한 유지보수 및 서비스를 제공하는 파드를 배포할 때 가장 유용합니다.
예를 들어, 로그 수집 및 전달, 메트릭 집계 및 노드 자체의 기능을 증가시키는 서비스 실행은 데몬 세트에 대한 인기 있는 후보입니다. 데몬 세트는 종종 기본적인 서비스를 제공하며 전체 장비에서 필요하기 때문에, 다른 컨트롤러가 특정 호스트에 파드를 할당하는 것을 방지하는 파드 스케줄링 제한을 우회할 수 있습니다. 예를 들어, 고유한 책임 때문에 마스터 서버는 일반 파드 스케줄링에 사용할 수 없도록 구성되지만, 데몬 세트는 필수 서비스가 실행되도록 파드별로 제한을 무시할 수 있습니다.
작업과 크론 작업
지금까지 설명한 작업들은 모두 장기간 실행되는 서비스와 유사한 수명주기를 가정하고 있습니다. 쿠버네티스는 작업이라는 워크로드를 사용하여 실행 중인 컨테이너가 작업을 완료한 후 일정 시간이 지난 후에 성공적으로 종료될 것으로 예상되는 보다 작업 중심적인 워크플로를 제공합니다. 작업은 지속적인 서비스를 실행하는 대신 일회성 또는 일괄 처리를 수행해야 하는 경우 유용합니다.
작업에 대한 건물은 cron 작업입니다. Linux 및 Unix류 시스템의 전통적인 cron 데몬처럼 스케줄에 따라 스크립트를 실행하는 Kubernetes의 cron 작업은 스케줄링 구성 요소를 사용하여 작업을 실행할 수 있는 인터페이스를 제공합니다. Cron 작업은 미래에 실행하거나 정기적으로 반복해서 실행할 작업을 예약하는 데 사용될 수 있습니다. Kubernetes cron 작업은 기본적으로 단일 운영 체제가 아닌 클러스터를 플랫폼으로 사용하여 고전적인 cron 동작을 다시 구현한 것입니다.
기타 Kubernetes 구성 요소
클러스터에서 실행할 수 있는 워크로드를 넘어서 Kubernetes는 애플리케이션을 관리하고 네트워킹을 제어하며 지속성을 활성화하는 데 도움이 되는 여러 가지 추상화를 제공합니다. 여기서는 몇 가지 일반적인 예시를 논의하겠습니다.
Kubernetes 서비스
지금까지 “서비스”라는 용어를 전통적인 Unix류 의미로 사용해 왔습니다. 즉, 요청에 응답할 수 있는 네트워크에 연결된 장기 실행 프로세스를 나타냅니다. 그러나 Kubernetes에서 서비스는 팟의 기본 내부 로드 밸런서 및 대사자 역할을 하는 구성 요소입니다. 서비스는 동일한 기능을 수행하는 팟의 논리적인 모음을 그룹화하여 단일 개체로 표시합니다.
이를 통해 특정 유형의 모든 백엔드 컨테이너를 추적하고 라우팅할 수 있는 서비스를 배포할 수 있습니다. 내부 소비자는 서비스에서 제공하는 안정적인 엔드포인트만 알아야합니다. 한편, 서비스 추상화를 통해 필요에 따라 백엔드 작업 단위를 확장하거나 교체할 수 있습니다. 서비스의 IP 주소는 라우팅되는 팟에 대한 변경과 관계없이 안정적으로 유지됩니다. 서비스를 배포함으로써 쉽게 발견성을 확보하고 컨테이너 디자인을 간소화할 수 있습니다.
다른 응용 프로그램 또는 외부 사용자에게 하나 이상의 팟에 액세스를 제공해야하는 경우 항상 서비스를 구성해야합니다. 예를 들어, 인터넷에서 접근 가능해야하는 웹 서버가 실행되는 팟 집합이있는 경우 서비스가 필요한 추상화를 제공합니다. 마찬가지로, 웹 서버가 데이터를 저장하고 검색해야하는 경우 내부 서비스를 구성하여 데이터베이스 팟에 액세스할 수 있습니다.
기본적으로 서비스는 내부 라우팅 가능한 IP 주소를 사용하여만 사용할 수 있지만, 여러 전략 중 하나를 선택하여 클러스터 외부에서 사용할 수 있습니다. NodePort 구성은 각 노드의 외부 네트워킹 인터페이스에 정적 포트를 열어 작동합니다. 외부 포트로의 트래픽은 내부 클러스터 IP 서비스를 사용하여 자동으로 적절한 팟으로 라우팅됩니다.
또한, LoadBalancer 서비스 유형은 클라우드 제공업체의 Kubernetes 로드 밸런서 통합을 사용하여 서비스로 라우팅하기 위한 외부 로드 밸런서를 생성합니다. 클라우드 컨트롤러 매니저는 내부 서비스 서비스 주소를 사용하여 적절한 리소스를 생성하고 구성합니다.
볼륨 및 지속적인 볼륨
컨테이너 환경에서 데이터를 신뢰할 수 있게 공유하고 컨테이너 재시작 사이에 가용성을 보장하는 것은 많은 도커 환경에서의 과제입니다. 컨테이너 런타임은 종종 컨테이너의 수명을 초과하는 저장소를 컨테이너에 연결하는 메커니즘을 제공하지만, 구현은 일반적으로 유연성이 부족합니다.
이를 해결하기 위해 Kubernetes는 데이터를 팟 내의 모든 컨테이너가 공유하고 팟이 종료될 때까지 사용할 수 있도록 하는 자체 볼륨 추상화를 사용합니다. 이는 긴밀하게 결합된 팟이 복잡한 외부 메커니즘 없이도 파일을 쉽게 공유할 수 있음을 의미합니다. 팟 내의 컨테이너 실패는 공유 파일에 대한 액세스에 영향을 미치지 않습니다. 팟이 종료되면 공유 볼륨이 파괴되므로 실제로 지속적인 데이터에 대한 좋은 솔루션이 아닙니다.
지속적인 볼륨은 팟 수명 주기에 묶여 있지 않은 더 견고한 저장소를 추상화하는 메커니즘입니다. 대신, 관리자는 사용자가 실행 중인 팟에 대해 요청하고 요구할 수 있는 저장소 리소스를 구성할 수 있습니다. 팟이 지속적인 볼륨을 사용한 후에는, 볼륨의 회수 정책이 수동으로 삭제되거나 데이터와 함께 즉시 제거될지 여부를 결정합니다. 지속적인 데이터는 노드 기반 장애로부터 보호하고 로컬로 사용 가능한 저장소보다 더 큰 양의 저장소를 할당하는 데 사용될 수 있습니다.
레이블 및 주석
A Kubernetes organizational abstraction related to, but outside of the other concepts, is labeling. A label in Kubernetes is a semantic tag that can be attached to Kubernetes objects to mark them as a part of a group. These can then be selected for when targeting different instances for management or routing. For instance, each of the controller-based objects use labels to identify the pods that they should operate on. Services use labels to understand the backend pods they should route requests to.
레이블은 간단한 키-값 쌍으로 제공됩니다. 각 단위는 하나 이상의 레이블을 가질 수 있지만, 각 단위당 각 키에 대해 하나의 항목만 가질 수 있습니다. 일반적으로 “이름” 키는 일반 목적 식별자로 사용되지만, 개발 단계, 공개 가능성, 응용 프로그램 버전 등 다른 기준으로 객체를 추가로 분류할 수 있습니다.
주석은 객체에 임의의 키-값 정보를 첨부할 수 있는 유사한 메커니즘입니다. 레이블은 Pod를 선택 기준과 일치시키는 데 유용한 의미 정보에 사용되어야 하지만, 주석은 더 자유로우며 구조화되지 않은 데이터를 포함할 수 있습니다. 일반적으로 주석은 선택 목적에 도움이 되지 않는 객체에 풍부한 메타데이터를 추가하는 방법입니다.
결론
Source:
https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes