만약 클러스터에 스케쥴러가 없으면 어떻게 하실 것인가요? 내장된 스케쥴러에 의존하지 않고 직접 파드를 예약하려고 합니다. 이때 스케쥴러는 백엔드에서 어떻게 작동할까요? 간단한 pod definition file부터 시작하도록 하겠습니다. 모든 파드에는 Node Name이라는 필드가 있습니다. 디폴트로는 값이 들어가 있지 않습니다. 일반적으로 definition file을 만들 때 지정하지 않고, Kubernetes가 자동으로 추가하는 필드입니다. 스케쥴러는 모든 파드들을 검사하면서 Node Name속성이 설정되지 않은 파드를 찾습니다. 이들이 바로 스케쥴링 후보들입니다. 그다음에는 스케쥴링 알고리즘을 사용하여 파드에 적합한 노드를 고릅니다. 골랐으면 파드를 그 노드에 스케쥴링합니다. 이때 바인딩 오브젝트를 생성하면서 파드의 Node Name에 그 노드의 이름이 들어가게 됩니다.
만약 모니터링하고 스케쥴링할 스케쥴러가 없다면 어떻게 할까요? 이 상태에서 파드는 계속 보류중(Panding)입니다. 이를 해결하려면 수동으로 파드를 노드에 할당해야 합니다. 스케쥴러 없이 파드를 스케쥴링하는 가장 쉬운 방법은 파드를 생성할 때 pod sepcification file에서 Node Name에 노드 이름을 지정하는 것입니다. 이렇게 하면 파드가 지정된 노드에 할당됩니다. Node Name에 노드를 지정하는 것은 파드를 만들 때만 가능합니다. 이미 파드가 생성된 경우에 파드를 노드에 할당하고 싶다면 어떻게 해야 할까요? Kubernetes는 파드의 Node Name속성을 수정하지 못하게 해놓았습니다. 이럴 때에는 바인딩 오브젝트를 만들고, 파드의 바인딩 API에 POST 리퀘스트를 보내면 됩니다. 이 방식은 실제로 스케쥴러가 수행하는 작업을 따라한 것입니다. 아래와 같이 바인딩 오브젝트를 만듭니다.
apiVersion: v1 kind: Binding metadata: name: nginx target: apiVersion: v1 kind: Node name: node02
바인딩 객체에서 target하위의 name에 노드 이름이 들어갑니다. 그런 다음, 바인딩 API에 POST request를 보냅니다.
request를 보낼 때에는, YAML과 동일한 내용을 JSON으로 변환한 데이터를 사용해야 합니다.
테스트 통과 완료
Labels와 Selectors은 그룹화하는 표준 방법입니다.
다양한 종의 동물 세트가 있습니다. 사용자는 다양한 기준에 따라 이를 그룹화 및 필터링하기를 원합니다. 아래처럼 Class로 그룹화할 수 있습니다.
또한 가축인지 야생동물인지에 따라 그룹화할수도 있습니다.
그리고 색깔로 그룹화할 수도 있습니다.
그룹화 뿐 아니라 기준에 따른 필터링도 원합니다. 만약 '녹색 동물'이라고 기준을 잡았으면 아래와 같이 필터링 될 것입니다.
어떻게 분류를 하든지, 그룹화하고 필요에 따라 필터링하는 기능이 필요하며 이를 수행하는 가장 좋은 방법은 레이블을 사용하는 것입니다. 레이블은 각 항목에 첨부된 속성이므로 클래스, 종류 및 색상에 대한 속성을 각 항목에 추가합니다.
Selector는 이러한 항목을 필터링하는 데 도움이 됩니다. 예를 들어 클래스가 포유류라고 하면 포유류 목록이 표시되고 색상이 녹색과 같다고 하면 녹색 포유류가 표시됩니다. 사용자가 올바른 콘텐츠를 필터링하고 찾는 데 도움이 되는 YouTube 비디오 또는 블로그에 태그를 지정하는 키워드와 같이 Selector와 label은 모든 곳에서 사용되는 것을 볼 수 있습니다. 온라인 스토어에서 항목에 추가된 레이블을 보면 제품을 보기 위해 다양한 종류의 필터를 추가하는 데 도움이 됩니다.
그렇다면 Kubernetes에서 Label과 Selector는 어떻게 사용됩니까? 우리는 Kubernetes, 파드, 서비스, ReplicaSet, Deploy 등에서 다양한 유형의 오브젝트를 많이 만들었습니다. Kubernetes의 경우 이 모든 것이 서로 다른 오브젝트입니다.
시간이 지남에 따라 클러스터에 이러한 오브젝트가 수백 또는 수천 개 있게 될 수 있습니다. 그런 다음 유형별로 오브젝트를 그룹화하거나 애플리케이션 또는 기능별로 개체를 보는 것과 같이 다양한 범주별로 다양한 개체를 필터링하고 볼 수 있는 방법이 필요합니다. 그것이 무엇이든지 label과 selector를 사용하여 오브젝트를 각 오브젝트에 대해 애플리케이션이나 기능에 따라 레이블을 부착하여 그룹화하고 선택할 수 있습니다. 그런 다음 선택하는 동안 특정 오브젝트를 필터링할 조건을 지정합니다. 예를 들면 app = App1 처럼요.
그렇다면 Kubernetes에서 레이블을 정확히 어떻게 지정합니까? Pod Definition file 의 metadata에서 labels이라는 섹션을 작성하십시오. 그 아래에 다음과 같은 키 값 형식으로 레이블을 추가합니다. 원하는 만큼 레이블을 추가할 수 있습니다.
apiVersion: v1
kind: Pod
metadata:
name: simple-webapp
labels:
app: App1
function: Front-end
spec:
containers:
- name: simple-webapp
image: simple-webapp
ports:
- containerPort: 8080
파드가 생성되면 레이블이 있는 파드를 선택하려면 selector 옵션과 함께 kubectl get pods 커맨드를 사용하고 app = App1과 같은 조건을 지정합니다.
kubectl get pods --selector app=App1
이것은 레이블 및 selector 의 사용 사례 중 하나였습니다. Kubernetes 오브젝트는 내부적으로 레이블과 selector를 사용하여 서로 다른 오브젝트를 함께 연결합니다.
예를 들어, 3개의 서로 다른 파드로 구성된 ReplicaSet를 생성하려면 먼저 파드 정의에 레이블을 지정하고 ReplicaSet에서 seledtor를 사용하여 파드를 그룹화합니다.
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: simple-webapp
labels:
app: App1
function: Front-end
spec:
replicas: 3
selector:
matchLabels:
app: App1
template:
metadata:
labels:
app: App1
function: Front-end
spec:
containers:
- name: simple-webapp
image: simple-webapp
ReplicaSet Definition 파일에서 두 위치에 정의된 레이블을 볼 수 있습니다. 여기는 초보자가 실수하는 좋은 곳이니 주의해서 봐주세요. 템플릿 섹션 아래에 정의된 레이블은 파드에 구성된 레이블입니다. 상단에 표시되는 레이블은 ReplicaSet 자체의 레이블입니다.
ReplicaSet가 Pod를 검색하고 있기 때문에 지금은 ReplicaSet의 레이블에 대해 크게 걱정하지 않습니다. ReplicaSet의 레이블은 ReplicaSet를 검색하는 다른 오브젝트를 구성하는 경우에 사용됩니다.
ReplicaSet를 파드에 연결하기 위해 파드에 정의된 레이블과 일치하도록 ReplicaSet spec 아래의 selector 필드를 구성합니다. 단일 label로 매칭된다면 하나만 사용해도 됩니다. 그러나 label은 같지만 기능이 다른 다른 Pod가 있을 수 있다고 생각되면 두 레이블을 모두 지정하여 ReplicaSet에서 올바른 부분이 발견되도록 할 수 있습니다. ReplicaSet 생성 시 레이블이 일치하면 ReplicaSet이 성공적으로 생성됩니다.
서비스와 같은 다른 오브젝트에 대해서도 동일하게 작동합니다. 서비스가 생성되면 서비스 definition 파일에 정의된 selector를 사용하여 ReplicaSet Definition 파일의 파드에 설정된 레이블을 일치시킵니다.
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: App1
ports:
- protocol: TCP
port: 80
targetPort: 9376
마지막으로 주석을 살펴보겠습니다. 레이블과 selector는 오브젝트를 그룹화하고 선택하는 데 사용되는 반면, 주석은 정보 제공 목적으로 기타 세부 정보를 기록하는 데 사용됩니다.
예를 들어 이름, 버전, 빌드 정보 등과 같은 도구 세부 정보 또는 일종의 통합 목적으로 사용될 수 있는 연락처 세부 정보, 전화 번호, 이메일 ID 등입니다.
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: simple-webapp
labels:
app: App1
function: Front-end
annotations:
buildversion: 1.34
spec:
replicas: 3
selector:
matchLabels:
app: App1
template:
metadata:
labels:
app: App1
function: Front-end
spec:
containers:
- name: simple-webapp
image: simple-webapp
테스트 통과 완료