Openshift Administration (Node)

안녕하세요 조영호입니다.

오늘은 실제로 오픈시프트를 어떻게 운영하는지에 대해 공유하고자 합니다.

다룰 내용이 너무 많아서 오늘은 아래 항목 중 Node 관련해서 포스팅을 하도록 하겠습니다. 나머지 시리즈도 기대해주세요!

• Managing Node
• Managing Pods
• Managing Garbage Collection
• Allocating Node Resources
• Analyzing Cluster Capacity

 

첫 번째, 내용은 Managing Node입니다.

Node
노드는 Master, Worker 두가지 노드가 존재한다.

• Master Node : 클러스터를 관리하는 역할을 하며 API Server, ETCD, Controller Manager Server라는 Components를 가지고있다.마스터 노드는 지속적으로 워커 노드의 유효성을 확인하기 위해 Health Check를 한다. 
  • API Server : 파드를 노드에 할당하고 Service 구성에 따라 Pod를 동기화 시키는 역할을 한다.
  • ETCD : Master의 상태를 저장하며 다른 Component들은 ETCD가 가진 Master의 상태를 바라본다.
  • Controller Manager Server : ETCD의 상태를 바라보며 상태 변경시 API를 사용해 Replication Controller의 상태를 변경한다
• Worker Node : 워커노드는 컨테이너의 실행 환경(Runtime)을 제공한다. Docker, Kubelet, Service Proxy 등을 포함한다.
  • Kubelet : 각 워커 노드는 Kubelet을 가지고 있으며 Kubelet은 YAML로 작성 된 Container Manifest(명세서)대로 노드를 업데이트하는 역할을 한다. Kubelet은 Manifest대로 Container를 지속 및 실행 되도록 하며 ETCD를 보고 상태 변경에 따른다.

Listing Node

• oc get nodes
  • 노드들의 Name, Stauts, Roles, Age, Version 을 출력한다.
  • 노드의 역할에는 Master, Infra, Compute가 있는데, 보통 싱글 마스터인 경우 마스터 노드에 Master, Infra(OCP 환경 실행) 역할을 같이 주고 Worker 노드에 Compute 역할을 준다. 
• oc get nodes -o wide
  : 단순 get 명령어로 출력되는 결과 외에 추가로 Internal-IP, External-IP, OS-Image, Kernel Version, Container Runtime이 나온다
• oc get node <NodeName>
  : 특정 노드의 정보만 가져옵니다.
• oc describe node <NodeName>
  : 특정 노드의 detail을 가져옵니다. (아래 내용 참고)

Conditions:

Type	Status	Reason
OutOfDisk	False	KubeletHasSufficientDisk
MemoryPressure	False	KubeletHasSufficientMemory
DiskPressure	False	KubeletHasNoDiskPressure
Ready	True	KubeletReady
PIDPressure	False	KubeletHasSufficientPID

Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.)

CPU Requests	CPU Limits	Memory Requests	Memory Limits
500m (25%)	200m (10%)	1112Mi (14%)	400Mi (5%)

 

Adding Hosts

• Ansible의 playbook을 사용해서 사용자를 추가합se니다.

Modifying Nodes

• 오픈시프트는 설치와 동시에 각 노드 그룹을 관리하는 ConfigMap이 생성됩니다(node-config-master, infra, compute 등). 각 노드의 ConfigMap은 /etc/origin/node/node-config.yaml에서 수정할 수 있습니다.
• Auth, DNS, Network, Volume 등을 설정할 수 있다.

Labeling Nodes

• oc label node <NodeName> key=value
  : label은 selector로 사용되며 key=value 형태를 가진다. key 혹은 그 자리에 올 label을 가지고 사용자가 node를 포함한 컴포넌트들을 쉽게 다룰 수 있다. label은 k8s 내부적으로는 사용되지는 않고 단순 명명 규칙이다. 
• oc get node -l key
  : lable이 key로 지정 된 노드를 불러온다. 타 명령어 옵션에서 --selector=key로 사용하면 된다.

Listing Pod on Nodes

• oc adm manage-node <NodeName> --list-pods
  : 특정 노드에 있는 모든 파드를 출력한다. oc get pod는 선택된 프로젝트에 있는 pod들만 보여준다는 차이가 있다.
• oc adm manage-node <NodeName> --list-pods -o json | yaml
  : JSON이나 YAML형태로 POD의 정보를 출력한다.
• oc adm manage-node <NodeName> --list-pods --pod-selector=<key> -o json | yaml
  : 특정 노드의 특정 파드를 JSON이나 YAML 형태로 출력한다.

Marking Nodes as unscheduled or scheduled

• oc adm manage-node <NodeName> --schedulable=false
  : 특정 노드를 unschduled로 상태를 변경합니다. 정상적인 노드는 scheduled 상태를 가지고 있으며 노드에 적재 될 준비가 되었다는 의미입니다. 노드나 파드를 삭제하거나 할때 unscheduled 상태로 변경합니다.

Evacuating Pods or Nodes

• oc adm drain <NodeName> [--pod-selector='']
  : 특정 노드의 파드들을 이주 시킵니다. 이 작업을 하기 위해서는 우선 해당 노드를 unschduled로 변경해야합니다. 기본적으로 replication controller가 지원하는 파드만 대피시킬 수 있으며 replication controller는 타 노드에 새 파드를 만들고, 지정된 노드에서 기존 파드를 삭제하는 방식으로 동작합니다. (실제로, Node1의 파드들을 지우면 Node2로 파드들이 옮겨갑니다)
• oc adm drain <NodeName> --ignore-daemonsets=true
  : 단순 drain 명령으로 demonset은 지워지지 않습니다. 해당 옵션을 통해 지울 수 있습니다.

Rebooting node

쿠버네티스는 무 중단 서비스를 제공한다는 장점이 있습니다. 과연 노드를 리부트해도 서비스가 중단되지 않을까요? 예를들어, 한개의 노드에서만 서비스 중인 A파드가 존재한다고 가정해봅시다. 우리가 해당 노드를 재 시작하거나 노드에 문제가 생기면 어떻게 될까요? 당연히 A파드는 stopped 될 것이고 서비스도 중단 될 것입니다. 그러면 어떻게 해결해야 할까요? 해당 노드에 있는 A파드를 다른 노드에 옮긴 뒤 재부팅을 해야합니다. 노드의 Infra role은 OCP 환경을 실행하는 노드의 label인데요, 이 Infra 노드가 적어도 3개로 운영이 되어야 합니다.

• ex 1 ) 1개의 Infra 노드만 있는 경우
  해당 노드를 재부팅하면 파드들이 갈 곳이 없으니 중단됩니다.
• ex 2 ) 2개의 Infra 노드가 있는 경우
  2개의 Infra 노드가 있는 경우를 생각보겠습니다. A노드에서 B노드로 모든 파드를 이동시킨 뒤 A노드가 재부팅에 들어갑니다. 아직까지는 A파드의 서비스가 정상적으로 작동하고 있습니다. B노드에 B파드가 A노드에서 옮겨온 A파드와 엔드포인트가 겹치면 해당 서비스는 충돌이 일어나고 A노드가 부팅이 되어 다시 A파드가 옮겨갈 때 까지는 서비스가 중단 됩니다. 그래서 HA를 구성하기 위해서는 3개 이상의 Infra 노드가 필요합니다.

Modifying Nodes

OCP는 설치 시 openshift-node 프로젝트에 노드 그룹별로 아래와 같은 configmap을 생성하며 이를 편집해 Node를 수정할 수 있습니다.

• oc get cm -n openshigt-node
  : 결과는 아래와 같습니다.
  node-config-master
  node-config-infra
  node-config-compute
  node-config-all-in-one
  node-config-master-infra

각 노드의 Sync 파드는 Configmap을 바라보며 변경 사항을 감시합니다. 각 노드에는 /etc/origin/node/node-config.yaml 파일이 추가되며 Sync 파드(동기화 파드)는 Configmap의 변경에 따라 node-config.yaml을 수정합니다.

• cat /etc/origin/node/node-config.yaml
  : Master 노드에서 실행하면 master=true, infra=true를 볼 수 있고 Worker 노드에서 실행하면 compute=true를 볼 수 있습니다.
• oc edit cm node-config-compute -n openshift-node
  : 각 configmap은 위 명령어로 확인해 볼 수 있습니다. 다만 손수 configmap을 수정하는 것은 공식적으로 권장하고 있지 않습니다.

Configuring Node resouces

Configmap의 kubeletArguments 섹션을 수정해서 노드의 리소스를 조정할 수 있습니다.

• oc edit cm node-config-compute -n openshift-node
  :
  kubeletArguments:
   pods-per-core: - "10" #core당 운영할 수 있는 최소 pod 수
   max-pods: - "40" #1개 코어당 최소 10개에서 40개까지 pod를 운영할 수 있다.
   resolv-conf: - "/etc/resolv.conf"  #DNS 설정
   image-gc-high-threshold: - "90"  #GC는 image도 삭제를 하는데 최근 사용한 기록부터 삭제한다. high는 gc 이후에 사용할 disk양
   image-gc-low-threshold: - "80"  #low는 gc 이전에 사용할 disk 양으로, default 80%이며 이 수치가 gc의 트리거 역할을 한다.
   kube-api-qps: - "20"  #초당 API 쿼리 수
   kube-api-burst: - "40"

Logging

• oc get events
  : 사용자가 수행한 행동들에 대해 로그가 남는다. Action Kind, Message, Reason 등이 출력되며 Pod의 killing, pulling, starting 또는 replicationController 수정 등의 로그가 남는다. 
• oc logs <PodName>
  : 특정 파드의 로그를 출력한다.
• oc logs -f dc/<DeplymentConfigName>
  : DeploymentConfig의 로그를 출력한다.

 

참고

https://docs.openshift.com/