[IBM Cloud 강의번역 프로젝트] - ch2-3. Introduction to Kubernetes Objects

IBM Cloud 1기 활동 - 강의번역 프로젝트.

원본 강의

cognitiveclass.ai/courses/kubernetes-course

Kubernetes and containers on IBM Cloud - Free Kubernetes course by IBM Cognitive Class

강의의 한글자막 제공을 위해 srt 파일로 번역하는 프로젝트를 진행 중입니다.

문맥이 어색하거나 내용이 잘못되었다고 느껴지시면 댓글로 남겨주세요.

---

 

이번 강의에서는 Kubernetes 객체들을 설명하겠습니다.

 

Kubernetes 객체는 영속성을 지니고 있습니다. 영속성이란, Kubernetes에서 이 객체를 한 번 생성할 경우 사용자가 삭제하거나 변경하지 않는 한 시스템에 계속 존재한다는 의미입니다. 이러한 방식으로 Kubernetes 객체는 클러스터의 상태를 정의합니다. 객체를 생성한다는 건, Kubernetes에게 '이 객체는 존재해야 한다'고 명령한 것과 같습니다. 따라서 시스템은 사용자가 생성한 객체가 실제로 계속 존재하도록 해야 합니다. Kubernetes 객체의 예시로는 Pods, namespace, Deployments, ConfigMaps, 그리고 volumnes가 있으며, 모두 이번 강의에서 다룰 예정입니다.

 

이 객체들을 다루려면 - 생성하거나, 수정하거나 삭제하려면 - Kubernetes API를 사용해야 합니다. 가장 일반적인 방법은 "kubectl" CLI를 사용하는 것입니다. CLI는 사용자를 대신하여 필요한 Kubernetes API를 호출합니다. 또는 Kubernetes에서 제공하는 클라이언트 라이브러리를 직접 사용할 수도 있습니다.

 

Kubernetes 객체는 크게 두 개의 주요 필드로 구성됩니다. 첫 번째는 사용자가 제공하는 "spec" 입니다. spec은 해당 객체의 목표 상태값을 지정합니다. 두 번째 필드는 Kubernetes가 제공하는 status입니다. status는 해당 객체의 현재 상태를 나타냅니다. status는 해당 객체의 status값이 바뀔 때마다 변경됩니다.

 

시스템의 목표는 당연히, 목표 상태값과 현재 상태가 일치하는 것이고, Kubernetes는 이 목표를 맞추기 위해 계속 동작합니다.

 

객체 유형을 설명하기에 앞서, 객체를 구성하는 몇 가지 특징들을 먼저 다루겠습니다. Namespaces는 물리적 클러스터를 가상화하는 역할을 합니다. Namespace를 활용해서, 하나의 클러스터를 여러 개의 독립된 클러스터처럼 다룰 수 있습니다. 여러 팀이 하나의 클러스터를 비용 절감의 목적으로, 또는 여러 개의 프로젝트를 분리할 목적으로 클러스터를 공유할 때 유용한 기능입니다. 클러스터를 사용하는 사용자 수가 많을 때 가장 빛을 발합니다.

 

 

 

 

클러스터는 이전 강의에 설명했던 Kubernetes 아키텍처를 저장하기 위해 여러 개의 Namespace를 자동으로 생성합니다. 예컨대 kube-system namespace가 이런 구성요소를 저장하고 있습니다. kube-system은 Kubernetes 시스템을 저장하는 용도로 쓰이는 만큼, 사용자 임의의 애플리케이션을 namespace에 넣지 않도록 유의해야 합니다. 대신, default namespace에서 사용자의 애플리케이션을 저장할 수 있습니다. 이 정도의 설정만으로도 사용자에게 충분한 경우가 있을 수 있습니다. 클러스터를 사용하는 팀이 하나뿐이고, 이 팀이 클러스터에 배포할 프로젝트도 하나뿐인 경우입니다. 추가로 분할하는 과정이 필요하지 않은 경우입니다.

 

 

하지만 만약 팀이 여럿이고 프로젝트도 여러 개라면, 서로 다른 일을 해야 하는 사용자가 많은 경우라면, 작업 공간을 분할하기 위해 namespace를 추가로 만들어야 합니다. 한 팀당, 또는 하나의 프로젝트에 고유의 namespace를 부여받을 수 있습니다. 관리자는 각자의 목적에 맞게 클러스터를 namespace로 나눌 수 있습니다. 몇 가지 일반적인 패턴을 설명드렸지만, 요점은, namespace는 하나의 클러스터를 여러 개의 가상 클러스터로 논리적 분리를 할 수 있다는 것입니다.

 

 

 

namespace의 마지막 특징으로는 객체의 이름이 통용되는 범위를 지정합니다. [강의안의 왼쪽을 보세요] 각 객체마다 이름이 있고, 해당 namespace의 해당 리소스 유형에서 이름은 고유한 값이어야 합니다. 예를 들어, myPod 이라는 Pod를 default namespace에 정의했다면 default namespace에서 pod을 생성할 때, myPod이라는 이름을 다시 사용할 수 없습니다. 만약 다른 namespace라면, myPod이라는 이름을 또 사용할 수 있습니다. 별도의 namespace이기 때문입니다. 동일한 namespace의 Deployment 객체는 myPod라는 이름을 사용할 수 있습니다. 리소스 유형이 다르기 때문입니다. 클러스터가 여러 개의 namespace를 참조하고 있다면, 각 namespace에 명명된 객체를 배포할 수 있습니다.

 

 

 

 

이 다이어그램에서는 맨 윗줄에 객체 유형을, 맨 아랫줄에는 객체 이름을 표시합니다. 여기 두 가지 다른 유형의 객체 배포되어 있습니다. 각각 Type A와 Type B 유형입니다. 각각의 namespace에서, Type A 객체와 Type B 객체의 이름은 같습니다. 객체의 타입이 다르기 때문에, 같은 이름을 써도 괜찮습니다. "team"은 별도의 namespace이므로, default namespace와 똑같이 Type A 유형의 객체를 동일한 이름으로 생성해도 괜찮습니다. 각각의 이름은 namespace 내에서만 고유해야 하므로, 아무런 문제가 없습니다.

 

만약 project namespace에서 동일한 이름의 Type A 객체를 다시 배포하려 하면, 하나의 namespace에서 동일한 유형의 객체에 같은 이름을 붙일 수 없기 때문에 배포되지 않습니다. 이름은, namespace 내에서 고유성 수준을 제공합니다.

 

 

 

만약 특정 객체에 고유성을 부여하지 않은 채 다른 속성을 제공하려면 라벨을 사용할 수 있습니다. 라벨은 특정 객체를 식별하기 위해 객체에 부착할 수 있는 키-값 쌍입니다. 고유성을 지니지 않습니다. 여러 개의 객체가 동일한 라벨을 부여받을 수 있습니다. 그렇다는 건, 라벨별로 객체를 그룹화하거나 조직화하는 게 가능하다는 뜻입니다.

 

이 작업을 가능하게 하는 게 selector 입니다. 라벨 선택자는 Kubernetes 그룹화 기능의 핵심입니다. 객체의 그룹을 식별하는 역할을 합니다. Kubernetes 컨트롤러가 라벨 선택자를 어떻게 사용하는지 곧 다룰 예정입니다.

 

 

이 다이어그램을 보면, Type A 유형의 객체 세 개가 default namespace에 배포되어 있습니다. 각각의 객체는 고유한 이름을 가지고 있고, 객체의 세 번째 줄에 라벨명이 기입되어 있습니다. 이 경우, 모든 객체가 'app' 이란 라벨명을 보유하고 있습니다. 이 라벨은 다양한 형태의 Kubernetes 구성이 가능하도록 세 개의 객체를 그룹화하는 역할을 합니다.

 

 

 

 

이제 Kubernetes 객체의 기본 개념을 어느 정도 이해하셨을 것입니다. 특히 namespace를 사용해서 클러스터를 가상화하는 법, namespace 안에서 이름 충돌이 발생하지 않도록 하는 법을 배웠습니다. 라벨이 고유성을 적용받지 않는다는 특징과, Kubernetes객체에 어떻게 적용할 수 있으며 라벨 선택자로 그룹화하는 데 쓰인다는 사실도 설명했습니다. 다음 강의에서는 Kubernetes의 기본적인 객체들을 배울 것입니다.