8.4. 인프라 머신 세트로 리소스 이동
일부 인프라 리소스는 기본적으로 클러스터에 배포됩니다. 다음과 같이 인프라 노드 선택기를 추가하여 생성한 인프라 머신 세트로 이동할 수 있습니다.
spec:
nodePlacement: 1
nodeSelector:
matchLabels:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
- 1
- 적절한 값이 설정된
nodeSelector
매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로nodeSelector
를 사용하거나 노드에 지정된 값에 따라<key>: <value>
쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 톨러레이션도 추가합니다.
모든 인프라 구성 요소에 특정 노드 선택기를 적용하면 OpenShift Container Platform에서 해당 라벨을 사용하여 노드에서 해당 워크로드를 예약 합니다.
8.4.1. 라우터 이동
라우터 Pod를 다른 머신 세트에 배포할 수 있습니다. 기본적으로 Pod는 작업자 노드에 배포됩니다.
사전 요구 사항
- OpenShift Container Platform 클러스터에서 추가 머신 세트를 구성합니다.
절차
라우터 Operator의
IngressController
사용자 정의 리소스를 표시합니다.$ oc get ingresscontroller default -n openshift-ingress-operator -o yaml
명령 출력은 다음 예제와 유사합니다.
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: creationTimestamp: 2019-04-18T12:35:39Z finalizers: - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller generation: 1 name: default namespace: openshift-ingress-operator resourceVersion: "11341" selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default uid: 79509e05-61d6-11e9-bc55-02ce4781844a spec: {} status: availableReplicas: 2 conditions: - lastTransitionTime: 2019-04-18T12:36:15Z status: "True" type: Available domain: apps.<cluster>.example.com endpointPublishingStrategy: type: LoadBalancerService selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default
ingresscontroller
리소스를 편집하고infra
레이블을 사용하도록nodeSelector
를 변경합니다.$ oc edit ingresscontroller default -n openshift-ingress-operator
spec: nodePlacement: nodeSelector: 1 matchLabels: node-role.kubernetes.io/infra: "" tolerations: - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved
- 1
- 적절한 값이 설정된
nodeSelector
매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로nodeSelector
를 사용하거나 노드에 지정된 값에 따라<key>: <value>
쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 허용 오차도 추가합니다.
라우터 pod가
infra
노드에서 실행되고 있는지 확인합니다.라우터 pod 목록을 표시하고 실행중인 pod의 노드 이름을 기록해 둡니다.
$ oc get pod -n openshift-ingress -o wide
출력 예
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES router-default-86798b4b5d-bdlvd 1/1 Running 0 28s 10.130.2.4 ip-10-0-217-226.ec2.internal <none> <none> router-default-955d875f4-255g8 0/1 Terminating 0 19h 10.129.2.4 ip-10-0-148-172.ec2.internal <none> <none>
이 예에서 실행중인 pod는
ip-10-0-217-226.ec2.internal
노드에 있습니다.실행중인 pod의 노드 상태를 표시합니다.
$ oc get node <node_name> 1
- 1
- pod 목록에서 얻은
<node_name>
을 지정합니다.
출력 예
NAME STATUS ROLES AGE VERSION ip-10-0-217-226.ec2.internal Ready infra,worker 17h v1.24.0
역할 목록에
infra
가 포함되어 있으므로 pod가 올바른 노드에서 실행됩니다.
8.4.2. 기본 레지스트리 이동
Pod를 다른 노드에 배포하도록 레지스트리 Operator를 구성합니다.
전제 조건
- OpenShift Container Platform 클러스터에서 추가 머신 세트를 구성합니다.
절차
config/instance
개체를 표시합니다.$ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml
출력 예
apiVersion: imageregistry.operator.openshift.io/v1 kind: Config metadata: creationTimestamp: 2019-02-05T13:52:05Z finalizers: - imageregistry.operator.openshift.io/finalizer generation: 1 name: cluster resourceVersion: "56174" selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster uid: 36fd3724-294d-11e9-a524-12ffeee2931b spec: httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623 logging: 2 managementState: Managed proxy: {} replicas: 1 requests: read: {} write: {} storage: s3: bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c region: us-east-1 status: ...
config/instance
개체를 편집합니다.$ oc edit configs.imageregistry.operator.openshift.io/cluster
spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: namespaces: - openshift-image-registry topologyKey: kubernetes.io/hostname weight: 100 logLevel: Normal managementState: Managed nodeSelector: 1 node-role.kubernetes.io/infra: "" tolerations: - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved
- 1
- 적절한 값이 설정된
nodeSelector
매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로nodeSelector
를 사용하거나 노드에 지정된 값에 따라<key>: <value>
쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 톨러레이션도 추가합니다.
레지스트리 pod가 인프라 노드로 이동되었는지 검증합니다.
다음 명령을 실행하여 레지스트리 pod가 있는 노드를 식별합니다.
$ oc get pods -o wide -n openshift-image-registry
노드에 지정된 레이블이 있는지 확인합니다.
$ oc describe node <node_name>
명령 출력을 확인하고
node-role.kubernetes.io/infra
가LABELS
목록에 있는지 확인합니다.
8.4.3. 모니터링 솔루션 이동
모니터링 스택에는 Prometheus, Thanos Querier 및 Alertmanager를 비롯한 여러 구성 요소가 포함되어 있습니다. Cluster Monitoring Operator는 이 스택을 관리합니다. 모니터링 스택을 인프라 노드에 재배포하기 위해 사용자 정의 구성 맵을 생성하고 적용할 수 있습니다.
절차
cluster-monitoring-config
구성 맵을 편집하고infra
레이블을 사용하도록nodeSelector
를 변경합니다.$ oc edit configmap cluster-monitoring-config -n openshift-monitoring
apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: |+ alertmanagerMain: nodeSelector: 1 node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute prometheusK8s: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute prometheusOperator: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute k8sPrometheusAdapter: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute kubeStateMetrics: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute telemeterClient: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute openshiftStateMetrics: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute thanosQuerier: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - key: node-role.kubernetes.io/infra value: reserved effect: NoSchedule - key: node-role.kubernetes.io/infra value: reserved effect: NoExecute
- 1
- 적절한 값이 설정된
nodeSelector
매개변수를 이동하려는 구성 요소에 추가합니다. 표시된 형식으로nodeSelector
를 사용하거나 노드에 지정된 값에 따라<key>: <value>
쌍을 사용할 수 있습니다. 인프라 노드에 테인트를 추가한 경우 일치하는 톨러레이션도 추가합니다.
모니터링 pod가 새 머신으로 이동하는 것을 확인합니다.
$ watch 'oc get pod -n openshift-monitoring -o wide'
구성 요소가
infra
노드로 이동하지 않은 경우 이 구성 요소가 있는 pod를 제거합니다.$ oc delete pod -n openshift-monitoring <pod>
삭제된 pod의 구성 요소가
infra
노드에 다시 생성됩니다.
8.4.4. 로깅 리소스 이동
Elasticsearch 및 Kibana와 같은 로깅 구성 요소용 Pod를 다른 노드에 배포하도록 Red Hat OpenShift Logging Operator를 구성할 수 있습니다. 설치된 위치에서 Red Hat OpenShift Logging Operator Pod를 이동할 수 없습니다.
예를 들어 높은 CPU, 메모리 및 디스크 요구 사항으로 인해 Elasticsearch Pod를 다른 노드로 옮길 수 있습니다.
사전 요구 사항
- Red Hat OpenShift Logging Operator 및 OpenShift Elasticsearch Operator를 설치했습니다.
절차
openshift-logging
프로젝트에서ClusterLogging
사용자 정의 리소스(CR)를 편집합니다.$ oc edit ClusterLogging instance
ClusterLogging
CR의 예apiVersion: logging.openshift.io/v1 kind: ClusterLogging # ... spec: logStore: elasticsearch: nodeCount: 3 nodeSelector: 1 node-role.kubernetes.io/infra: '' tolerations: - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved redundancyPolicy: SingleRedundancy resources: limits: cpu: 500m memory: 16Gi requests: cpu: 500m memory: 16Gi storage: {} type: elasticsearch managementState: Managed visualization: kibana: nodeSelector: 2 node-role.kubernetes.io/infra: '' tolerations: - effect: NoSchedule key: node-role.kubernetes.io/infra value: reserved - effect: NoExecute key: node-role.kubernetes.io/infra value: reserved proxy: resources: null replicas: 1 resources: null type: kibana # ...
검증
oc get pod -o wide
명령을 사용하여 구성 요소가 이동했는지 확인할 수 있습니다.
예를 들면 다음과 같습니다.
ip-10-0-147-79.us-east-2.compute.internal
노드에서 Kibana pod를 이동하려고 경우 다음을 실행합니다.$ oc get pod kibana-5b8bdf44f9-ccpq9 -o wide
출력 예
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kibana-5b8bdf44f9-ccpq9 2/2 Running 0 27s 10.129.2.18 ip-10-0-147-79.us-east-2.compute.internal <none> <none>
Kibana Pod를 전용 인프라 노드인
ip-10-0-139-48.us-east-2.compute.internal
노드로 이동하려는 경우 다음을 실행합니다.$ oc get nodes
출력 예
NAME STATUS ROLES AGE VERSION ip-10-0-133-216.us-east-2.compute.internal Ready master 60m v1.24.0 ip-10-0-139-146.us-east-2.compute.internal Ready master 60m v1.24.0 ip-10-0-139-192.us-east-2.compute.internal Ready worker 51m v1.24.0 ip-10-0-139-241.us-east-2.compute.internal Ready worker 51m v1.24.0 ip-10-0-147-79.us-east-2.compute.internal Ready worker 51m v1.24.0 ip-10-0-152-241.us-east-2.compute.internal Ready master 60m v1.24.0 ip-10-0-139-48.us-east-2.compute.internal Ready infra 51m v1.24.0
노드에는
node-role.kubernetes.io/infra : ''
레이블이 있음에 유의합니다.$ oc get node ip-10-0-139-48.us-east-2.compute.internal -o yaml
출력 예
kind: Node apiVersion: v1 metadata: name: ip-10-0-139-48.us-east-2.compute.internal selfLink: /api/v1/nodes/ip-10-0-139-48.us-east-2.compute.internal uid: 62038aa9-661f-41d7-ba93-b5f1b6ef8751 resourceVersion: '39083' creationTimestamp: '2020-04-13T19:07:55Z' labels: node-role.kubernetes.io/infra: '' ...
Kibana pod를 이동하려면
ClusterLogging
CR을 편집하여 노드 선택기를 추가합니다.apiVersion: logging.openshift.io/v1 kind: ClusterLogging # ... spec: # ... visualization: kibana: nodeSelector: 1 node-role.kubernetes.io/infra: '' proxy: resources: null replicas: 1 resources: null type: kibana
- 1
- 노드 사양의 레이블과 일치하는 노드 선택기를 추가합니다.
CR을 저장하면 현재 Kibana pod가 종료되고 새 pod가 배포됩니다.
$ oc get pods
출력 예
NAME READY STATUS RESTARTS AGE cluster-logging-operator-84d98649c4-zb9g7 1/1 Running 0 29m elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg 2/2 Running 0 28m elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj 2/2 Running 0 28m elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78 2/2 Running 0 28m collector-42dzz 1/1 Running 0 28m collector-d74rq 1/1 Running 0 28m collector-m5vr9 1/1 Running 0 28m collector-nkxl7 1/1 Running 0 28m collector-pdvqb 1/1 Running 0 28m collector-tflh6 1/1 Running 0 28m kibana-5b8bdf44f9-ccpq9 2/2 Terminating 0 4m11s kibana-7d85dcffc8-bfpfp 2/2 Running 0 33s
새 pod는
ip-10-0-139-48.us-east-2.compute.internal
노드에 있습니다.$ oc get pod kibana-7d85dcffc8-bfpfp -o wide
출력 예
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES kibana-7d85dcffc8-bfpfp 2/2 Running 0 43s 10.131.0.22 ip-10-0-139-48.us-east-2.compute.internal <none> <none>
잠시 후 원래 Kibana pod가 제거됩니다.
$ oc get pods
출력 예
NAME READY STATUS RESTARTS AGE cluster-logging-operator-84d98649c4-zb9g7 1/1 Running 0 30m elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg 2/2 Running 0 29m elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj 2/2 Running 0 29m elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78 2/2 Running 0 29m collector-42dzz 1/1 Running 0 29m collector-d74rq 1/1 Running 0 29m collector-m5vr9 1/1 Running 0 29m collector-nkxl7 1/1 Running 0 29m collector-pdvqb 1/1 Running 0 29m collector-tflh6 1/1 Running 0 29m kibana-7d85dcffc8-bfpfp 2/2 Running 0 62s
추가 리소스
- OpenShift Container Platform 구성 요소 이동에 대한 일반적인 지침은 모니터링 문서 를 참조하십시오.