CKA-5일차

📍 CKA 4일차
📍 Udemy-Certified Kubernetes Administrator (CKA) with Practice Tests 49-61

---

51. Manual Scheduling

모든 파드에는 nodeName이라는 필드가 있는데 기본값으로 설정되어 있지 않다. pod menifast file을 만들 때 이 필드를 지정하지 않아도 된다.
쿠버네티스가 자동으로 추가하기 때문이다.
스케줄러는 모든 파드를 살펴보고 이 속성이 없는 파드들을 찾는다.
그런 다음 스케줄링 알고리즘을 실행해서 파드의 올바른 노드를 식별한다.
일단 식별되면 바인딩 개체를 만들어 노드의 이름 속성을 설정해서 노드에 파드를 지정합니다.

만약 노드를 모니터링하고 스케줄링할 스케줄러가 없다면 어떻게 될까?
파드는 여전히 pending 상태이다.
이 경우, 직접 노드에 파드를 할당해줘야 한다.
스케줄러 없이 파드를 할당하는 가장 쉬운 방법은 파드 정의 파일의 spec 영역에 nodeName 필드를 해당 노드의 이름으로 설정하는 것이다. 이는 파드를 생성할 때에만 지정할 수 있다.

파드가 이미 생성되었는데 노드에 할당하고 싶으면 어떻게해야 할까?
쿠버네티스는 생성된 파드의 nodeName을 수정하지 못하게 한다.
그래서 이미 생성된 파드를 노드에 할당하는 방법은 바인딩 개체를 생성하고 파드의 바인딩 API에 post 요청을 보내는 것이다.
이는 실제 스케줄러가 하는 일을 모방하는 것이다.
바인딩 개체에서 노드 이름을 가진 대상 노드를 지정한다. 그런 다음 파드의 바인딩 API에 post 요청을 보낸다. 이때, JSON 포맷의 바인딩 개체의 data set을 사용해야 한다.

---

53. Solution - Manual Scheduling

기존의 pod를 삭제하고 파드 정의 파일을 통해 pod를 새로 생성하고 싶으면 kubectl replace --force 명령어를 사용하면 된다.

--watch 옵션을 붙여서 조회하면 변화가 있는지 감시하고 변화가 있으면 상태를 바꿔준다.

---

54. Labels and Selectors

label과 selector를 이용해 개체를 그룹화하고 선택할 수 있다.

파드 파일의 메타데이터에서 labels이라는 부분을 생성하고 그 아래에 이렇게 key: value 형식으로 label을 추가하면 된다.

--selector 옵션을 통해 label에 해당하는 파드를 조회할 수 있다.

쿠버네티스 오브젝트는 내부에서 label과 selector를 이용해서 서로 다른 오브젝트를 연결한다.
아래 예시는 세 개의 다른 파드로 구성된 ReplicaSet을 만들기 위해 먼저 template에 파드 정의를 label과 ReplicaSet의 selector를 이용해 파드를 그룹으로 묶는다.
1. 맨 위에 보이는 label은 ReplicaSet 자체의 label이다. ReplicaSet이 pod를 발견하게 해야 하므로 해당 label은 지금 신경쓰지 않는다.
2. ReplicaSet의 label은 ReplicaSet을 발견하기 위해 다른 개체를 구성할 때 사용될 것이다.
3. ReplicaSet을 pod에 연결하기 위해 ReplicaSet의 spec 영역의 selector 필드를 구성한다. pod에서 정의된 label과 일치하기 위해서이다.
제작 단계에서 label이 일치하면 ReplicaSet은 성공적으로 만들어진다.

서비스가 생성되면 ReplicaSet 정의 파일의 pod에 있는 label과 일치하기 위해 서비스 정의 파일에 정의된 selector를 사용한다.

마지막으로 annotaions 필드는 정보 수집 목적으로 다른 세부사항을 기록하는데 사용된다. 예를 들어 이름, 버전, 빌드 정보 같은 세부 정보나 연락처, 이메일 등이 기록될 수 있다.

---

56. Solutions - Labels and Selectors

개수를 세기 어려울 경우, --no-headers 옵션으로 헤더를 제외하고 행의 개수를 출력하는 명령어인 wc -l를 통해 원하는 개수를 쉽게 얻을 수 있다.

label을 여러개 지정하여 조회할 수 있다.

실험해보자!

🧐 ReplicaSet의 label을 붙이지 않았을 경우

🧐 ReplicaSet의 label을 붙인 경우

tier=nginx label을 selector로 지정하여 ReplicaSet을 조회할 수 있다.

---

57. Taints and Tolerations

Taints와 Tolerations는 파드를 어떤 노드로 스케줄링할 수 있는지 제한을 설정하기 위해 사용된다.

만약 제한이나 한계가 없다면 스케쥴러가 모든 노드에 파드를 배치해 균형이 맞도록 한다.

만약 Node1에 Taints가 설정되었고 Pod D만 Tolerations를 가졌다면 다른 Pod들은 Node1에 배치되지 못하고 Pod D만 Node1에 배치될 것이다.
이처럼 Taints는 노드에 세팅하고 Tolerations는 Pod에 설정한다.

kubectl 명령어를 통해 Taints를 Node에 설정할 수 있다.
kubectl taint nodes node-name key=value:taint-effect 명령어 형식이다.
taint-effect에는 세 가지 경우가 있다.

• NoSchedule: 파드를 노드에 올릴 예정이 없다.
• PreferNoSchedule: 일정이 없는 것을 선호한다. 하지만 NoSchedule을 장담할 수 없다.
• NoExecute: 실행 불가. 새 파드가 노드에서 지정되지 않고 노드 위에 기존 파드가 있다면 사용자가 거부하면 퇴거해야 한다는 뜻이다.

파드에 Tolerations를 추가하기 위해서 파드 정의 파일을 열고 spec 영역에 tolerations 필드를 추가해야 한다.
이 모든 값들은 더블로 인코딩 되어야 한다.

좀 더 명확한 이해를 위한 다음 예제이다.
어떤 Taints나 Tolerations가 없기 때문에 이와 같이 균형적으로 스케쥴되어 있다.

특별한 응용 프로그램을 위해 1번 노드를 할당하기로 한다. 응용 프로그램의 이름으로 1번 노드를 Taint하고 그 응용 프로그램이 속한 파드인 D에 Tolerance를 추가한다.
Taint-effect는 NoExecute로 설정한다.
Taint-effect가 노드에서 발생하면 C파드를 노드1에서 쫓아낸다.
파드D는 노드1에서 계속 달린다. 이는 파드D에 Toleration이 설정되어 있기 때문에 Taint-blue를 수용하기 때문이다.
이 경우 노드1은 파드D만 수용할 수 있다.

하지만 파드D가 항상 노드1에 있는 것은 아니다.
다른 노드에 적용된 Taints나 Tolerations가 없으니 파드D는 다른 두 노드 중 하나에 있을 수 있다.
이처럼 Taints와 Tolerations는 파드가 특정 노드로 가도록 하는 것이 아니라, 대신 노드가 특정 파드만 수용하도록 한다.
파드가 특정 노드에 스케쥴되도록 제한하는 게 요구사항이라면 이후에 배울 Node Affinity를 통해 가능하다.

클러스터에는 마스터 노드가 있지만 스케줄러는 마스터 노드에 어떤 파드도 스케줄링 할 수 없다.
왜냐하면 쿠버네티스 클러스터가 처음 설정되면 마스터 노드에 Taint 설정이 자동으로 되어서 마스터 노드에 파드가 지정되는 것을 막는다.
필요하다면 이 동작을 수정할 수 있지만 마스터 노드에 파드를 배포하지 않는 것이 모범 사례이다.

다음 명령어를 통해 마스터 노드의 Taint를 확인할 수 있다.

---

59. Solution - Taints and Tolerations

kubectl taint --help를 통해서 taint 명령의 자세한 옵션들과 예시를 확인할 수 있다.
taint를 설정하는 명령어

pod에 tolerations 추가

taint 명령에 -를 맨 뒤에 붙이면 taint를 삭제하는 명령이 된다.

---

60. Node Selectors

특정 노드에서만 작동하도록 파드의 한계를 설정하는 두 가지 방법이 있다.
첫번째 방법은 Node Selector이다.
nodeSelector라는 새 속성을 파드 정의 파일의 spec 영역에 추가하고 노드에 할당된 label을 명시하면 된다.

노드에 라벨을 붙이는 명령어는 다음과 같다.

Node Selector는 유용했지만 한계가 있다.
하나의 label과 selector을 통해 동작하기 때문에 훨씬 더 복잡한 요구사항을 들어줄 수 없다.

---

61. Node Affinity

Node Affinity는 특정 노드에 파드 배치를 제한하는 고급 기능을 제공한다.

아래 사진의 좌측은 nodeSelector를 정의했고 우측은 nodeAffinity를 정의했다.

다음은 작은 크기가 아닌 크기의 노드와 일치하는 nodeAffinity가 정의되어 있다.

다음은 key=size 라벨이 존재하는지 확인하는 nodeAffinity가 정의되어 있다.

nodeAffinity와 일치하는 노드가 없으면 어떻게 될까?
이 모든 건 nodeAffinity 아래 속성인 긴 문자열에 따라 결정된다.

• Available
  • requiredDuringSchedulingIgnoredDuringExecution

    • DuringScheduling: required(필수), 지정된 nodeAffinity 규칙과 함께 파드를 노드에 배포해야 한다. 만약 nodeAffinity와 일치하는 노드를 찾지 못하면 schedule이 될 수 없다.
      • DuringExecution: ignored(무시), 파드는 계속해서 실행되고 nodeAffinity의 변화는 영향을 미치지 않는다.

  • preferredDuringSchedulingIgnoredDuringExecution

    • DuringScheduling: preferred(최선), 일치하는 노드가 없을 경우 scheduler는 nodeAffinity를 무시하고 해당 파드를 가능한 아무 노드에 배치한다.
    • DuringExecution: ignored(무시), 파드는 계속해서 실행되고 nodeAffinity의 변화는 영향을 미치지 않는다.

• Planned
  • requiredDuringSchedulingRequiredDuringExecution

    • DuringScheduling: required(필수), 지정된 nodeAffinity 규칙과 함께 파드를 노드에 배포해야 한다. 만약 nodeAffinity와 일치하는 노드를 찾지 못하면 schedule이 될 수 없다.
    • DuringExecution: required(필수), nodeAffinity 규칙이 변경되면 이에 부합하지 않는 노드에서 실행 중인 파드를 퇴출하거나 종료한다.