2장. 인프라 구성 요소

핵심 컨트롤 플레인 구성 요소, API 서버 및 컨트롤러 관리자 구성 요소는 kubelet에서 작동하는 정적 Pod 로 실행됩니다.

etcd가 동일한 호스트에 공동 배치된 마스터의 경우 etcd도 정적 포드로 이동합니다. RPM 기반 etcd는 여전히 마스터가 아닌 etcd 호스트에서 지원됩니다.

또한 노드 구성 요소 openshift-sdn 및 openvswitch 는 systemd 서비스 대신 DaemonSet을 사용하여 실행됩니다.

그림 2.1. 컨트롤 플레인 호스트 아키텍처 변경

컨트롤 플레인 구성 요소가 정적 포드로 실행되는 경우에도 마스터 호스트는 마스터 및 노드 구성 항목에 설명된 대로 /etc/origin/master/master-config.yaml 파일에서 구성을 계속 제공합니다.

시작 순서 개요

Hyperkube 는 모든 Kubernetes(kube-apiserver,controller- manager,스케줄러,프록시, kubelet)를 포함하는 바이너리입니다. 시작 시 kubelet 은 kubepods.slice 를 생성합니다. 다음으로 kubelet 은 kubepods.slice 내에 QoS 수준 슬라이스 burstable.slice 및 best-effort.slice 를 생성합니다. Pod가 시작되면 kubelet 은 pod<UUID-of-pod>.slice 형식을 사용하여 Pod 수준 슬라이스를 생성하고 CRI(컨테이너 런타임 인터페이스)의 다른 쪽의 런타임에 해당 경로를 전달합니다. 그런 다음 Docker 또는 CRI-O가 Pod 수준 슬라이스 내에 컨테이너 수준 슬라이스를 생성합니다.

미러 Pod

마스터 노드의 kubelet은 kube-system 프로젝트의 클러스터에 표시되도록 각 컨트롤 플레인 정적 Pod에 대해 API 서버에 미러 Pod를 자동으로 생성합니다. 이러한 정적 포드의 매니페스트는 기본적으로 마스터 호스트의 /etc/origin/node/pods 디렉터리에 있는 openshift-ansible 설치 프로그램에서 설치합니다.

이러한 Pod에는 다음과 같은 hostPath 볼륨이 정의되어 있습니다.

정적 Pod에서 수행할 수 있는 작업 세트는 제한됩니다. 예를 들면 다음과 같습니다.

$ oc logs master-api-<hostname> -n kube-system

API 서버에서 표준 출력을 반환합니다. 그러나 다음을 수행합니다.

$ oc delete pod master-api-<hostname> -n kube-system

포드를 실제로 삭제하지 않습니다.

또 다른 예로 클러스터 관리자는 문제가 발생하는 경우 더 자세한 데이터를 제공하기 위해 API 서버의 로그 수준을 늘리는 등 일반적인 작업을 수행해야 할 수 있습니다. 이 값이 컨테이너 내부에서 실행되는 프로세스로 전달되므로 /etc/origin/master/master.env 파일을 편집해야 합니다. 여기서 OPTIONS 변수의 --loglevel 매개 변수를 수정할 수 있습니다. 변경 사항을 적용하려면 컨테이너 내부에서 실행 중인 프로세스를 다시 시작해야 합니다.

마스터 서비스 다시 시작

컨트롤 플레인 정적 포드에서 실행 중인 컨트롤 플레인 서비스를 다시 시작하려면 마스터 호스트에서 master-restart 명령을 사용합니다.

마스터 API를 다시 시작하려면 다음을 수행합니다.

# master-restart api

컨트롤러를 다시 시작하려면 다음을 수행합니다.

# master-restart controllers

etcd를 다시 시작하려면 다음을 수행합니다.

# master-restart etcd

마스터 서비스 로그 보기

컨트롤 플레인 정적 Pod에서 실행되는 컨트롤 플레인 서비스의 로그를 보려면 해당 구성 요소에 대해 master-logs 명령을 사용합니다.

# master-logs api api

# master-logs controllers controllers

# master-logs etcd etcd

클러스터에 단일 장애 지점이 없는지 확인하기 위해 선택적으로 HA(고가용성)를 위해 마스터를 구성할 수 있습니다.

마스터 가용성에 대한 우려를 완화하려면 다음 두 가지 활동을 사용하는 것이 좋습니다.

HAProxy와 함께 기본 HA 방법을 사용하는 경우 마스터 구성 요소는 다음과 같은 가용성을 갖습니다.

클러스터형 etcd에는 쿼럼에 대한 홀수의 호스트가 필요하지만 마스터 서비스에는 홀수의 호스트가 있다는 쿼럼이나 요구 사항이 없습니다. 그러나 HA에 대해 두 개 이상의 마스터 서비스가 필요하므로 마스터 서비스 및 etcd를 함께 배치할 때 일관된 홀수의 호스트를 유지하는 것이 일반적입니다.

각 노드에는 Pod를 설명하는 YAML 파일인 컨테이너 매니페스트에서 지정한 대로 노드를 업데이트하는 kubelet이 있습니다. kubelet은 매니페스트 세트를 사용하여 해당 컨테이너가 시작되고 계속 실행되도록 합니다.

다음을 통해 kubelet에 컨테이너 매니페스트를 제공할 수 있습니다.

각 노드는 해당 노드의 API에 정의된 서비스를 반영하는 간단한 네트워크 프록시도 실행합니다. 이를 통해 노드는 백엔드 집합에서 간단한 TCP 및 UDP 스트림 전달을 수행할 수 있습니다.

다음은 Kubernetes의 노드 오브젝트 정의의 예입니다.

apiVersion: v1 1
kind: Node 2
metadata:
  creationTimestamp: null
  labels: 3
    kubernetes.io/hostname: node1.example.com
  name: node1.example.com 4
spec:
  externalID: node1.example.com 5
status:
  nodeInfo:
    bootID: ""
    containerRuntimeVersion: ""
    kernelVersion: ""
    kubeProxyVersion: ""
    kubeletVersion: ""
    machineID: ""
    osImage: ""
    systemUUID: ""

노드의 구성이 마스터에서 부트스트랩되므로 노드가 마스터에서 사전 정의된 구성과 클라이언트 및 서버 인증서를 가져옵니다. 따라서 노드 간 차이점을 줄이고 더 많은 구성을 중앙 집중화하고 원하는 상태에 클러스터가 병합되므로 더 빠른 노드 시작이 가능합니다. 인증서 교체 및 중앙 집중식 인증서 관리는 기본적으로 활성화되어 있습니다.

그림 2.2. 노드 부트스트랩 워크플로 개요

노드 서비스가 시작되면 노드는 클러스터에 참여하기 전에 /etc/origin/node/node.kubeconfig 파일 및 기타 노드 구성 파일이 있는지 확인합니다. 노드가 없는 경우 노드는 마스터에서 구성을 가져온 다음 클러스터에 결합합니다.

ConfigMaps 는 /etc/origin/node/node-config.yaml 의 노드 호스트에서 구성 파일을 채우는 클러스터에 노드 구성을 저장하는 데 사용됩니다. 기본 노드 그룹 및 해당 ConfigMap 세트의 정의는 클러스터 설치에서 노드 그룹 및 호스트 맵핑 정의를 참조하십시오.

노드 부트스트랩 워크플로

자동 노드 부트스트랩 프로세스는 다음 워크플로우를 사용합니다.

노드 설정 워크플로

노드의 구성을 소싱하려면 다음 워크플로우를 사용합니다.

노드 구성 수정

노드의 구성은 openshift-node 프로젝트에서 적절한 ConfigMap을 편집하여 수정합니다. /etc/origin/node/node-config.yaml 은 직접 수정해서는 안 됩니다.

예를 들어 node -config-compute 그룹에 있는 노드 의 경우 다음을 사용하여 ConfigMap을 편집합니다.

$ oc edit cm node-config-compute -n openshift-node