클러스터 관리

인프라 노드는 OpenShift Container Platform 환경의 일부를 실행하도록 레이블이 지정된 노드입니다. 현재 노드 재부팅을 관리하는 가장 쉬운 방법은 인프라를 실행하는 데 사용 가능한 노드가 3개 이상 있는지 확인하는 것입니다. 아래 시나리오는 두 개의 노드만 사용할 수 있을 때 OpenShift Container Platform에서 실행되는 애플리케이션의 서비스 중단으로 이어질 수 있는 일반적인 실수를 보여줍니다.

세 개의 인프라 노드를 사용하는 동일한 프로세스로 인해 서비스가 중단되지 않습니다. 그러나 Pod 예약으로 인해 비워진 후 되돌린 마지막 노드가 0개의 레지스트리를 실행 중인 상태로 남아 있습니다. 다른 두 노드는 각각 두 개의 레지스트리와 하나의 레지스트리를 실행합니다. 최상의 솔루션은 Pod 유사성 방지를 사용하는 것입니다. 이는 현재 테스트할 수 있지만 프로덕션 워크로드에서 아직 지원되지 않는 알파 기능입니다.

Pod 유사성 방지 는 노드 유사성 방지 와 약간 다릅니다. Pod를 배포할 다른 적절한 위치가 없는 경우 노드 유사성 방지를 위반할 수 있습니다. Pod 유사성 방지를 필수 또는 기본으로 설정할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity: 1
      preferredDuringSchedulingIgnoredDuringExecution: 2
      - weight: 100 3
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: docker-registry 4
              operator: In 5
              values:
              - default
          topologyKey: kubernetes.io/hostname

이 예제에서는 컨테이너 이미지 레지스트리 포드에 docker-registry=default 레이블이 있다고 가정합니다. Pod 유사성 방지에서는 모든 Kubernetes 일치 표현식을 사용할 수 있습니다.

마지막 필수 단계는 /etc/origin/master/scheduler.json 에서 MatchInterPodAffinity 스케줄러 서술자를 활성화하는 것입니다. 이 경우 두 개의 인프라 노드만 사용할 수 있고 하나의 인프라 노드만 재부팅하면 컨테이너 이미지 레지스트리 포드가 다른 노드에서 실행되지 않습니다. oc get pods 는 적절한 노드를 사용할 수 있을 때까지 포드를 준비되지 않은 것으로 보고합니다. 노드를 사용할 수 있고 모든 Pod가 준비 상태가 되면 다음 노드를 재시작할 수 있습니다.

대부분의 경우 OpenShift Container Platform 라우터를 실행하는 Pod는 호스트 포트를 노출합니다. PodFitsPorts 스케줄러 서술자를 사용하면 동일한 포트를 사용하는 라우터 Pod가 동일한 노드에서 실행되지 않으며 Pod 유사성 방지를 구현할 수 있습니다. 라우터가 고가용성을 위해 IP 페일오버를 사용하는 경우 추가로 필요한 것은 없습니다. 고가용성을 위해 AWS Elastic Load Balancing과 같은 외부 서비스를 사용하는 라우터 Pod의 경우 해당 서비스에서 라우터 Pod 재시작에 대응해야 합니다.

드물지만 라우터 포드에 호스트 포트가 구성되어 있지 않을 수 있습니다. 이러한 경우 인프라 노드에 권장되는 재시작 프로세스를 따라야 합니다.

노드 구성 맵에 kubelet 인수를 추가하여 노드 리소스를 구성할 수 있습니다.

/etc/origin/node/node-config.yaml 파일에서 하나의 매개변수는 노드에 예약할 수 있는 최대 Pod 수 를 제어합니다. max-pods 옵션을 사용하는 경우 노드의 Pod 수를 제한합니다. 이 값을 초과하면 다음과 같은 결과가 발생할 수 있습니다.

max-pods 는 노드의 속성에 관계없이 노드가 실행할 수 있는 Pod 수를 고정 값으로 설정합니다. 클러스터 제한 은 max-pods에 대해 지원되는 최대 값을 문서화합니다.

kubeletArguments:
  max-pods:
    - "250"

위 예를 사용하여 max-pods 의 기본값은 250 입니다.

etcd 호스트가 손상되고 /etc/etcd/etcd.conf 파일이 손실된 경우 다음 절차를 사용하여 복원하십시오.

이 예제에서 백업 파일은 /backup/etcd-config-<timestamp>/etcd/etcd.conf 경로에 저장되며, 여기에서 외부 NFS 공유, S3 버킷 또는 기타 스토리지 솔루션으로 사용할 수 있습니다.

etcd 구성 파일을 복원한 후 정적 pod를 다시 시작해야 합니다. etcd 데이터를 복원한 후 수행됩니다.

정적 포드에서 etcd를 복원하기 전에 다음을 수행하십시오.

정적 포드에서 etcd를 복원하려면 다음을 수행하십시오.

프로시저

마스터 노드에서 etcd를 정적 포드로 실행하지 않으면 다른 etcd 호스트를 추가해야 할 수도 있습니다.

프로시저

현재 etcd 클러스터 수정

etcd 인증서를 생성하려면 값을 사용자 환경의 값으로 교체하여 openssl 명령을 실행하십시오.

새 etcd 호스트 수정

각 OpenShift Container Platform 마스터 수정

프로시저

다음 단계에서는 새 pvc가 작성되었다고 가정합니다.

프로시저

프로시저

마스터 노드에서 etcd를 정적 포드로 실행하지 않으면 다른 etcd 호스트를 추가해야 할 수도 있습니다.

프로시저

현재 etcd 클러스터 수정

etcd 인증서를 생성하려면 값을 사용자 환경의 값으로 교체하여 openssl 명령을 실행하십시오.

새 etcd 호스트 수정

각 OpenShift Container Platform 마스터 수정

API 서버는 master-config.yaml 파일의 projectRequestTemplate 매개 변수로 식별된 템플릿을 기반으로 프로젝트를 자동으로 프로비저닝합니다. 매개 변수가 정의되지 않은 경우 API 서버는 요청된 이름으로 프로젝트를 생성하는 기본 템플릿을 생성하고 요청하는 사용자를 해당 프로젝트의 "admin" 역할에 할당합니다.

사용자 정의 프로젝트 템플릿을 만들려면:

프로젝트 요청을 제출하면 API에서 다음 매개변수를 템플릿으로 대체합니다.

API에 대한 액세스 권한은 self-provisioner 역할 및 self-provisioner s 클러스터 역할 바인딩을 사용하여 개발자에게 부여됩니다. 이 역할은 기본적으로 인증된 모든 개발자에게 제공됩니다.

인증된 사용자 그룹이 새 프로젝트를 자체 프로비저닝하지 못하도록 할 수 있습니다.

클러스터 관리자는 Pod 배치를 특정 노드로 제한하도록 클러스터 수준 기본 노드 선택기를 설정할 수 있습니다.

/etc/origin/master/master-config.yaml 에서 마스터 구성 파일을 편집하고 기본 노드 선택기의 값을 추가합니다. 이는 지정된 nodeSelector 값이 없는 모든 프로젝트에서 생성된 Pod에 적용됩니다.

...
projectConfig:
  defaultNodeSelector: "type=user-node,region=east"
...

변경 사항을 적용하려면 OpenShift 서비스를 다시 시작하십시오.

# master-restart api
# master-restart controllers

노드 선택기를 사용하여 개별 프로젝트를 생성하려면 프로젝트를 생성할 때 --node-selector 옵션을 사용합니다. 예를 들어 여러 리전이 있는 OpenShift Container Platform 토폴로지가 있는 경우 노드 선택기를 사용하여 특정 OpenShift Container Platform 프로젝트를 특정 리전의 노드에만 배포하도록 제한할 수 있습니다.

다음은 myproject 라는 새 프로젝트를 생성하고 사용자 노드 및 east 라는 레이블이 지정된 노드에 포드를 배포함을 나타냅니다.

$ oc adm new-project myproject \
    --node-selector='type=user-node,region=east'

이 명령이 실행되면 지정된 프로젝트에 포함된 모든 포드의 관리자 세트 노드 선택기가 됩니다.

oc adm new-project 명령을 사용하면 주석 섹션이 프로젝트에 추가됩니다. 프로젝트를 편집하고 openshift.io/node-selector 값을 변경하여 기본값을 재정의할 수 있습니다.

...
metadata:
  annotations:
    openshift.io/node-selector: type=user-node,region=east
...

다음 명령을 사용하여 기존 프로젝트 네임스페이스에 대한 기본값을 재정의할 수도 있습니다.

# oc patch namespace myproject -p \
    '{"metadata":{"annotations":{"openshift.io/node-selector":"node-role.kubernetes.io/infra=true"}}}'

openshift.io/node-selector 가 빈 문자열(ocadm new-project --node-selector="")로 설정된 경우 클러스터 전체 기본값이 설정된 경우에도 프로젝트에관리자 설정 노드 선택기가 없습니다. 즉, 클러스터 관리자로서 개발자 프로젝트를 노드의 하위 집합으로 제한하고 인프라 또는 기타 프로젝트에서 전체 클러스터를 예약할 수 있도록 기본값을 설정할 수 있습니다.

OpenShift Container Platform 개발자는 노드를 추가로 제한하려는 경우 Pod 구성에 노드 선택기를 설정 할 수 있습니다. 이는 프로젝트 노드 선택기 외에도 노드 선택기 값이 있는 모든 프로젝트의 노드 선택기 값을 지정할 수 있습니다.

예를 들어 위의 주석(openshift.io/node-selector: type=user-node,region=east)을 사용하여 프로젝트가 생성되고 개발자가 해당 프로젝트의 Pod에 다른 노드 선택기를 설정합니다(예: =classified ) Pod는 세 개의 라벨(type=user-node,region=east, parcel= classified)이 모두 있는 노드에만 예약됩니다. 포드에서 region=west 을 설정하면 포드가 region =east 및 region= west 레이블이 있는 노드가 요구되며 작동하지 않습니다. 레이블을 하나의 값으로만 설정할 수 있으므로 포드는 예약되지 않습니다.

플러그인 구성에는 한 번 실행 Pod의 기본 활성 데드라인이 포함되어야 합니다. 이 데드라인은 전역적으로 적용되지만 프로젝트별로 대체될 수 있습니다.

admissionConfig:
  pluginConfig:
    RunOnceDuration:
      configuration:
        apiVersion: v1
        kind: RunOnceDurationConfig
        activeDeadlineSecondsOverride: 3600 1
....

관리자는 실행 Pod에 대한 글로벌 최대 기간을 지정하는 것 외에도 주석(openshift.io/active-deadline-seconds-override)을 특정 프로젝트에 추가하여 글로벌 기본값을 재정의할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: egress-1
  labels:
    name: egress-1
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"
spec:
  containers:
  - name: egress-router
    image: openshift3/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 1
      value: 192.168.12.99
    - name: EGRESS_GATEWAY 2
      value: 192.168.12.1
    - name: EGRESS_DESTINATION 3
      value: 203.0.113.25
  nodeSelector:
    site: springfield-1 4

apiVersion: v1
kind: Service
metadata:
  name: egress-1
spec:
  ports:
  - name: http
    port: 80
  - name: https
    port: 443
  type: ClusterIP
  selector:
    name: egress-1

OpenShift Container Platform 클러스터 관리자는 송신 정책을 사용하여 일부 또는 모든 Pod가 클러스터 내에서 액세스할 수 있는 외부 주소를 제한할 수 있습니다.

예를 들어 지정된 IP 범위에 대한 <project A> 액세스를 허용하지만 < project B> 에 대한 동일한 액세스를 거부하도록 다양한 송신 정책을 사용하여 프로젝트를 구성할 수 있습니다.

프로젝트 관리자는 EgressNetworkPolicy 오브젝트 를 생성하거나 프로젝트에서 생성한 개체를 편집할 수 없습니다. 또한 EgressNetworkPolicy 를 생성할 수 있는 몇 가지 제한 사항이 있습니다.

이러한 제한 사항을 위반하면 프로젝트의 송신 정책이 손상되고 모든 외부 네트워크 트래픽이 삭제될 수 있습니다.

기존 프로젝트 네트워크에 프로젝트를 참여하려면 다음을 수행합니다.

$ oc adm pod-network join-projects --to=<project1> <project2> <project3>

위의 예에서 <project2> 및 <project 3> 의 모든 Pod 및 서비스는 <project1&gt; 의 모든 Pod 및 서비스에 액세스할 수 있으며 그 반대의 경우도 마찬가지입니다. 서비스는 IP 또는 정규화된 DNS 이름(<service>.<pod_namespace>.svc.cluster.local)을 통해 액세스할 수 있습니다. 예를 들어 myproject 프로젝트에서 db 라는 서비스에 액세스하려면 db.myproject.svc.cluster.local 을 사용합니다.

또는 특정 프로젝트 이름을 지정하는 대신 --selector=<project_selector> 옵션을 사용할 수 있습니다.

함께 참여한 네트워크를 확인하려면 다음을 수행합니다.

$ oc get netnamespaces

그런 다음 NETID 열을 확인합니다. 동일한 포드 네트워크에 있는 프로젝트는 동일한 NetID를 갖습니다.

프로젝트에서 클러스터의 모든 Pod 및 서비스에 액세스할 수 있도록 허용하려면 다음을 수행합니다.

$ oc adm pod-network make-projects-global <project1> <project2>

위의 예에서 <project1> 및 <project2> 의 모든 Pod 및 서비스는 이제 클러스터의 모든 Pod 및 서비스에 액세스할 수 있으며 그 반대의 경우도 마찬가지입니다.

또는 특정 프로젝트 이름을 지정하는 대신 --selector=<project_selector> 옵션을 사용할 수 있습니다.

OpenShift Container Platform 송신 라우터는 다른 업무에 사용되지 않는 프라이빗 소스 IP 주소를 사용하여 지정된 원격 서버로 트래픽을 리디렉션하는 서비스를 실행합니다. 서비스를 사용하면 포드가 허용된 IP 주소에서만 액세스할 수 있도록 설정된 서버와 통신할 수 있습니다.

배포 고려 사항

Egress 라우터는 노드의 기본 네트워크 인터페이스에 두 번째 IP 주소와 MAC 주소를 추가합니다. 베어 메탈에서 OpenShift Container Platform을 실행하지 않는 경우 추가 주소를 허용하도록 하이퍼바이저 또는 클라우드 공급자를 구성해야 할 수 있습니다.

특히 다음이 활성화되어 있는지 확인하십시오.

송신 라우터 모드

송신 라우터는 리디렉션 모드,HTTP 프록시 모드 및 DNS 프록시 모드의 세 가지 모드로 실행될 수 있습니다. 리디렉션 모드는 HTTP 및 HTTPS를 제외한 모든 서비스에서 작동합니다. HTTP 및 HTTPS 서비스의 경우 HTTP 프록시 모드를 사용하십시오. IP 주소 또는 도메인 이름이 있는 TCP 기반 서비스는 DNS 프록시 모드를 사용하십시오.

apiVersion: v1
kind: Pod
metadata:
  name: egress-multi
  labels:
    name: egress-multi
  annotations:
    pod.network.openshift.io/assign-macvlan: "true"
spec:
  initContainers:
  - name: egress-router
    image: registry.redhat.io/openshift3/ose-egress-router
    securityContext:
      privileged: true
    env:
    - name: EGRESS_SOURCE 1
      value: 192.168.12.99/24
    - name: EGRESS_GATEWAY
      value: 192.168.12.1
    - name: EGRESS_DESTINATION 2
      value: |
        80   tcp 203.0.113.25
        8080 tcp 203.0.113.26 80
        8443 tcp 203.0.113.26 443
        203.0.113.27
    - name: EGRESS_ROUTER_MODE
      value: init
  containers:
  - name: egress-router-wait
    image: registry.redhat.io/openshift3/ose-pod

일부 클러스터 관리자는 EgressNetworkPolicy 모델 또는 송신 라우터 모델에 맞지 않는 나가는 트래픽에 대한 작업을 수행할 수 있습니다. 경우에 따라 iptables 규칙을 직접 생성하여 이 작업을 수행할 수 있습니다.

예를 들어 특정 대상에 대한 트래픽을 기록하거나 초당 특정 수 이상의 나가는 연결을 방지하는 규칙을 만들 수 있습니다.

OpenShift Container Platform은 사용자 지정 iptables 규칙을 자동으로 추가하는 방법을 제공하지 않지만 관리자가 수동으로 이러한 규칙을 추가할 수 있는 장소를 제공합니다. 각 노드는 시작 시 필터 테이블에 OPENSHIFT-ADMIN-OUTPUT-RULES 라는 빈 체인을 생성합니다( 체인이 아직 존재하지 않는다고 가정). 관리자가 해당 체인에 추가된 규칙은 포드에서 클러스터 외부 대상으로 이동하는 모든 트래픽(다른 트래픽에 해당하지 않음)에 적용됩니다.

이 기능을 사용할 때 주의해야 할 몇 가지 사항이 있습니다.

NetworkPolicy 오브젝트를 사용하면 네임스페이스 내에서 라벨별로 서로 다른 Pod를 격리할 수 있습니다.

NetworkPolicy 오브젝트를 단일 네임스페이스에서 개별 포드의 많은 수에 적용하는 것은 비효율적입니다. Pod 레이블은 IP 수준에 존재하지 않으므로 NetworkPolicy 오브젝트는 pod Selector 로 선택한 모든 Pod 간에 가능한 모든 링크에 대해 별도의 OVS 흐름 규칙을 생성합니다.

예를 들어 NetworkPolicy 오브젝트 내의 spec podSelector 및 ingress podSelector가 각각 200개의 Pod와 일치하면 40000(200*200) OVS 흐름 규칙이 생성됩니다. 이로 인해 머신이 느려질 수 있습니다.

OVS 흐름 규칙을 줄이려면 네임스페이스를 사용하여 격리해야 하는 포드 그룹을 포함합니다.

namespace Selectors 또는 빈 podSelectors 를 사용하여 전체 네임스페이스 를 선택하는 NetworkPolicy 오브젝트는 네임스페이스의 VXLAN VNID와 일치하는 단일 OVS 흐름 규칙만 생성합니다.

원래 네임스페이스에서 분리할 필요가 없는 포드를 유지하고, 분리해야 하는 포드를 하나 이상의 네임스페이스로 이동합니다.

격리된 Pod에서 허용하려는 특정 트래픽을 허용하도록 추가 대상의 네임스페이스 간 정책을 생성합니다.

ovs-multitenant 플러그인을 사용하는 경우 라우터의 트래픽이 모든 네임스페이스에 자동으로 허용됩니다. 라우터는 일반적으로 기본 네임스페이스에 있고 모든 네임스페이스에서 해당 네임스페이스의 포드에서 연결을 허용하기 때문입니다. ovs-networkpolicy 플러그인에서는 자동으로 수행되지 않습니다. 따라서 기본적으로 네임스페이스를 격리하는 정책이 있는 경우 라우터가 액세스할 수 있도록 추가 단계를 수행해야 합니다.

한 가지 옵션은 각 서비스에 대한 정책을 생성하여 모든 소스에서 액세스할 수 있도록 하는 것입니다. 예를 들면 다음과 같습니다.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-to-database-service
spec:
  podSelector:
    matchLabels:
      role: database
  ingress:
  - ports:
    - protocol: TCP
      port: 5432

이렇게 하면 라우터가 서비스에 액세스할 수 있지만 다른 사용자의 네임스페이스의 포드도 액세스할 수 있습니다. 이러한 포드는 일반적으로 공용 라우터를 사용하여 서비스에 액세스할 수 있으므로 문제가 발생하지 않습니다.

또는 ovs-multitenant 플러그인과 같이 default 네임스페이스에서 전체 액세스를 허용하는 정책을 생성할 수 있습니다.

클러스터 관리자는 새 프로젝트가 생성될 때마다 기본 NetworkPolicy 오브젝트(한 개 이상)의 자동 생성을 활성화하도록 기본 프로젝트 템플릿을 수정할 수 있습니다. 이 작업을 수행하려면 다음을 수행합니다.

클러스터 역할 및 관련 규칙 집합을 보려면 다음을 수행합니다.

$ oc describe clusterrole.rbac
Name:		admin
Labels:		<none>
Annotations:	openshift.io/description=A user that has edit rights within the project and can change the project's membership.
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources							Non-Resource URLs	Resource Names	Verbs
  ---------							-----------------	--------------	-----
  appliedclusterresourcequotas					[]			[]		[get list watch]
  appliedclusterresourcequotas.quota.openshift.io		[]			[]		[get list watch]
  bindings							[]			[]		[get list watch]
  buildconfigs							[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs.build.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs/instantiate					[]			[]		[create]
  buildconfigs.build.openshift.io/instantiate			[]			[]		[create]
  buildconfigs/instantiatebinary				[]			[]		[create]
  buildconfigs.build.openshift.io/instantiatebinary		[]			[]		[create]
  buildconfigs/webhooks						[]			[]		[create delete deletecollection get list patch update watch]
  buildconfigs.build.openshift.io/webhooks			[]			[]		[create delete deletecollection get list patch update watch]
  buildlogs							[]			[]		[create delete deletecollection get list patch update watch]
  buildlogs.build.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  builds							[]			[]		[create delete deletecollection get list patch update watch]
  builds.build.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  builds/clone							[]			[]		[create]
  builds.build.openshift.io/clone				[]			[]		[create]
  builds/details						[]			[]		[update]
  builds.build.openshift.io/details				[]			[]		[update]
  builds/log							[]			[]		[get list watch]
  builds.build.openshift.io/log					[]			[]		[get list watch]
  configmaps							[]			[]		[create delete deletecollection get list patch update watch]
  cronjobs.batch						[]			[]		[create delete deletecollection get list patch update watch]
  daemonsets.extensions						[]			[]		[get list watch]
  deploymentconfigrollbacks					[]			[]		[create]
  deploymentconfigrollbacks.apps.openshift.io			[]			[]		[create]
  deploymentconfigs						[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs.apps.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs/instantiate					[]			[]		[create]
  deploymentconfigs.apps.openshift.io/instantiate		[]			[]		[create]
  deploymentconfigs/log						[]			[]		[get list watch]
  deploymentconfigs.apps.openshift.io/log			[]			[]		[get list watch]
  deploymentconfigs/rollback					[]			[]		[create]
  deploymentconfigs.apps.openshift.io/rollback			[]			[]		[create]
  deploymentconfigs/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs.apps.openshift.io/scale			[]			[]		[create delete deletecollection get list patch update watch]
  deploymentconfigs/status					[]			[]		[get list watch]
  deploymentconfigs.apps.openshift.io/status			[]			[]		[get list watch]
  deployments.apps						[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions/rollback				[]			[]		[create delete deletecollection get list patch update watch]
  deployments.apps/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.extensions/scale					[]			[]		[create delete deletecollection get list patch update watch]
  deployments.apps/status					[]			[]		[create delete deletecollection get list patch update watch]
  endpoints							[]			[]		[create delete deletecollection get list patch update watch]
  events							[]			[]		[get list watch]
  horizontalpodautoscalers.autoscaling				[]			[]		[create delete deletecollection get list patch update watch]
  horizontalpodautoscalers.extensions				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimages						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimages.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamimports						[]			[]		[create]
  imagestreamimports.image.openshift.io				[]			[]		[create]
  imagestreammappings						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreammappings.image.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams							[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams/layers						[]			[]		[get update]
  imagestreams.image.openshift.io/layers			[]			[]		[get update]
  imagestreams/secrets						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams.image.openshift.io/secrets			[]			[]		[create delete deletecollection get list patch update watch]
  imagestreams/status						[]			[]		[get list watch]
  imagestreams.image.openshift.io/status			[]			[]		[get list watch]
  imagestreamtags						[]			[]		[create delete deletecollection get list patch update watch]
  imagestreamtags.image.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  jenkins.build.openshift.io					[]			[]		[admin edit view]
  jobs.batch							[]			[]		[create delete deletecollection get list patch update watch]
  limitranges							[]			[]		[get list watch]
  localresourceaccessreviews					[]			[]		[create]
  localresourceaccessreviews.authorization.openshift.io		[]			[]		[create]
  localsubjectaccessreviews					[]			[]		[create]
  localsubjectaccessreviews.authorization.k8s.io		[]			[]		[create]
  localsubjectaccessreviews.authorization.openshift.io		[]			[]		[create]
  namespaces							[]			[]		[get list watch]
  namespaces/status						[]			[]		[get list watch]
  networkpolicies.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  persistentvolumeclaims					[]			[]		[create delete deletecollection get list patch update watch]
  pods								[]			[]		[create delete deletecollection get list patch update watch]
  pods/attach							[]			[]		[create delete deletecollection get list patch update watch]
  pods/exec							[]			[]		[create delete deletecollection get list patch update watch]
  pods/log							[]			[]		[get list watch]
  pods/portforward						[]			[]		[create delete deletecollection get list patch update watch]
  pods/proxy							[]			[]		[create delete deletecollection get list patch update watch]
  pods/status							[]			[]		[get list watch]
  podsecuritypolicyreviews					[]			[]		[create]
  podsecuritypolicyreviews.security.openshift.io		[]			[]		[create]
  podsecuritypolicyselfsubjectreviews				[]			[]		[create]
  podsecuritypolicyselfsubjectreviews.security.openshift.io	[]			[]		[create]
  podsecuritypolicysubjectreviews				[]			[]		[create]
  podsecuritypolicysubjectreviews.security.openshift.io		[]			[]		[create]
  processedtemplates						[]			[]		[create delete deletecollection get list patch update watch]
  processedtemplates.template.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  projects							[]			[]		[delete get patch update]
  projects.project.openshift.io					[]			[]		[delete get patch update]
  replicasets.extensions					[]			[]		[create delete deletecollection get list patch update watch]
  replicasets.extensions/scale					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers/scale					[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers.extensions/scale			[]			[]		[create delete deletecollection get list patch update watch]
  replicationcontrollers/status					[]			[]		[get list watch]
  resourceaccessreviews						[]			[]		[create]
  resourceaccessreviews.authorization.openshift.io		[]			[]		[create]
  resourcequotas						[]			[]		[get list watch]
  resourcequotas/status						[]			[]		[get list watch]
  resourcequotausages						[]			[]		[get list watch]
  rolebindingrestrictions					[]			[]		[get list watch]
  rolebindingrestrictions.authorization.openshift.io		[]			[]		[get list watch]
  rolebindings							[]			[]		[create delete deletecollection get list patch update watch]
  rolebindings.authorization.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  rolebindings.rbac.authorization.k8s.io			[]			[]		[create delete deletecollection get list patch update watch]
  roles								[]			[]		[create delete deletecollection get list patch update watch]
  roles.authorization.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  roles.rbac.authorization.k8s.io				[]			[]		[create delete deletecollection get list patch update watch]
  routes							[]			[]		[create delete deletecollection get list patch update watch]
  routes.route.openshift.io					[]			[]		[create delete deletecollection get list patch update watch]
  routes/custom-host						[]			[]		[create]
  routes.route.openshift.io/custom-host				[]			[]		[create]
  routes/status							[]			[]		[get list watch update]
  routes.route.openshift.io/status				[]			[]		[get list watch update]
  scheduledjobs.batch						[]			[]		[create delete deletecollection get list patch update watch]
  secrets							[]			[]		[create delete deletecollection get list patch update watch]
  serviceaccounts						[]			[]		[create delete deletecollection get list patch update watch impersonate]
  services							[]			[]		[create delete deletecollection get list patch update watch]
  services/proxy						[]			[]		[create delete deletecollection get list patch update watch]
  statefulsets.apps						[]			[]		[create delete deletecollection get list patch update watch]
  subjectaccessreviews						[]			[]		[create]
  subjectaccessreviews.authorization.openshift.io		[]			[]		[create]
  subjectrulesreviews						[]			[]		[create]
  subjectrulesreviews.authorization.openshift.io		[]			[]		[create]
  templateconfigs						[]			[]		[create delete deletecollection get list patch update watch]
  templateconfigs.template.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]
  templateinstances						[]			[]		[create delete deletecollection get list patch update watch]
  templateinstances.template.openshift.io			[]			[]		[create delete deletecollection get list patch update watch]
  templates							[]			[]		[create delete deletecollection get list patch update watch]
  templates.template.openshift.io				[]			[]		[create delete deletecollection get list patch update watch]


Name:		basic-user
Labels:		<none>
Annotations:	openshift.io/description=A user that can get basic information about projects.
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources						Non-Resource URLs	Resource Names	Verbs
  ---------						-----------------	--------------	-----
  clusterroles						[]			[]		[get list]
  clusterroles.authorization.openshift.io		[]			[]		[get list]
  clusterroles.rbac.authorization.k8s.io		[]			[]		[get list watch]
  projectrequests					[]			[]		[list]
  projectrequests.project.openshift.io			[]			[]		[list]
  projects						[]			[]		[list watch]
  projects.project.openshift.io				[]			[]		[list watch]
  selfsubjectaccessreviews.authorization.k8s.io		[]			[]		[create]
  selfsubjectrulesreviews				[]			[]		[create]
  selfsubjectrulesreviews.authorization.openshift.io	[]			[]		[create]
  storageclasses.storage.k8s.io				[]			[]		[get list]
  users							[]			[~]		[get]
  users.user.openshift.io				[]			[~]		[get]


Name:		cluster-admin
Labels:		<none>
Annotations:	authorization.openshift.io/system-only=true
		openshift.io/description=A super-user that can perform any action in the cluster. When granted to a user within a project, they have full control over quota and membership and can perform every action...
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources	Non-Resource URLs	Resource Names	Verbs
  ---------	-----------------	--------------	-----
  		[*]			[]		[*]
  *.*		[]			[]		[*]


Name:		cluster-debugger
Labels:		<none>
Annotations:	authorization.openshift.io/system-only=true
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources	Non-Resource URLs	Resource Names	Verbs
  ---------	-----------------	--------------	-----
  		[/debug/pprof]		[]		[get]
  		[/debug/pprof/*]	[]		[get]
  		[/metrics]		[]		[get]


Name:		cluster-reader
Labels:		<none>
Annotations:	authorization.openshift.io/system-only=true
		rbac.authorization.kubernetes.io/autoupdate=true
PolicyRule:
  Resources							Non-Resource URLs	Resource Names	Verbs
  ---------							-----------------	--------------	-----
  								[*]			[]		[get]
  apiservices.apiregistration.k8s.io				[]			[]		[get list watch]
  apiservices.apiregistration.k8s.io/status			[]			[]		[get list watch]
  appliedclusterresourcequotas					[]			[]		[get list watch]

...

다양한 역할에 바인딩된 사용자와 그룹을 표시하는 현재 클러스터 역할 바인딩 세트를 보려면 다음을 수행합니다.

$ oc describe clusterrolebinding.rbac
Name:		admin
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	admin
Subjects:
  Kind			Name				Namespace
  ----			----				---------
  ServiceAccount	template-instance-controller	openshift-infra


Name:		basic-users
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	basic-user
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		cluster-admin
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-admin
Subjects:
  Kind			Name		Namespace
  ----			----		---------
  ServiceAccount	pvinstaller	default
  Group			system:masters


Name:		cluster-admins
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-admin
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:cluster-admins
  User	system:admin


Name:		cluster-readers
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-reader
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:cluster-readers


Name:		cluster-status-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	cluster-status
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated
  Group	system:unauthenticated


Name:		registry-registry-role
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:registry
Subjects:
  Kind			Name		Namespace
  ----			----		---------
  ServiceAccount	registry	default


Name:		router-router-role
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:router
Subjects:
  Kind			Name	Namespace
  ----			----	---------
  ServiceAccount	router	default


Name:		self-access-reviewers
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	self-access-reviewer
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated
  Group	system:unauthenticated


Name:		self-provisioners
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	self-provisioner
Subjects:
  Kind	Name				Namespace
  ----	----				---------
  Group	system:authenticated:oauth


Name:		system:basic-user
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:basic-user
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated
  Group	system:unauthenticated


Name:		system:build-strategy-docker-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:build-strategy-docker
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		system:build-strategy-jenkinspipeline-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:build-strategy-jenkinspipeline
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		system:build-strategy-source-binding
Labels:		<none>
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:build-strategy-source
Subjects:
  Kind	Name			Namespace
  ----	----			---------
  Group	system:authenticated


Name:		system:controller:attachdetach-controller
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:controller:attachdetach-controller
Subjects:
  Kind			Name			Namespace
  ----			----			---------
  ServiceAccount	attachdetach-controller	kube-system


Name:		system:controller:certificate-controller
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
Role:
  Kind:	ClusterRole
  Name:	system:controller:certificate-controller
Subjects:
  Kind			Name			Namespace
  ----			----			---------
  ServiceAccount	certificate-controller	kube-system


Name:		system:controller:cronjob-controller
Labels:		kubernetes.io/bootstrapping=rbac-defaults
Annotations:	rbac.authorization.kubernetes.io/autoupdate=true

...

모든 기본 클러스터 역할은 사용자 또는 그룹에 로컬로 바인딩할 수 있습니다.

사용자 지정 로컬 역할을 만들 수 있습니다.

로컬 역할 바인딩도 볼 수 있습니다.

다양한 역할에 바인딩된 사용자와 그룹을 표시하는 로컬 역할 바인딩의 현재 집합을 보려면 다음을 수행합니다.

$ oc describe rolebinding.rbac

기본적으로 로컬 역할 바인딩을 볼 때 현재 프로젝트가 사용됩니다. 또는 -n 플래그를 사용하여 프로젝트를 지정할 수 있습니다. 이 기능은 사용자에게 이미 admin 기본 클러스터 역할이 있는 경우 다른 프로젝트의 로컬 역할 바인딩을 확인하는 데 유용합니다.

$ oc describe rolebinding.rbac -n joe-project
Name:		admin
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	admin
Subjects:
  Kind	Name	Namespace
  ----	----	---------
  User	joe


Name:		system:deployers
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:deployer
Subjects:
  Kind			Name		Namespace
  ----			----		---------
  ServiceAccount	deployer	joe-project


Name:		system:image-builders
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:image-builder
Subjects:
  Kind			Name	Namespace
  ----			----	---------
  ServiceAccount	builder	joe-project


Name:		system:image-pullers
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	system:image-puller
Subjects:
  Kind	Name					Namespace
  ----	----					---------
  Group	system:serviceaccounts:joe-project

이미지에 새 서명을 추가하려면 HTTP PUT 메서드를 사용하여 JSON 페이로드를 확장 끝점으로 보낼 수 있습니다.

PUT /extensions/v2/<namespace>/<name>/signatures/<digest>

$ curl -X PUT --data @signature.json http://<user>:<token>@<registry_endpoint>:5000/extensions/v2/<namespace>/<name>/signatures/sha256:<digest>

서명 콘텐츠가 있는 JSON 페이로드에는 다음과 같은 구조가 있어야 합니다.

{
  "version": 2,
  "type":    "atomic",
  "name":    "sha256:4028782c08eae4a8c9a28bf661c0a8d1c2fc8e19dbaae2b018b21011197e1484@cddeb7006d914716e2728000746a0b23",
  "content": "<cryptographic_signature>"
}

name 필드에는 고유해야 하며 <digest>@<name> 형식의 이미지 서명 이름이 포함되어 있습니다. <digest> 는 이미지 이름을 나타내고 <name> 은 서명의 이름입니다. 서명 이름은 32자여야 합니다. <cryptographic_signature> 는 컨테이너/이미지 라이브러리에 설명된 사양을 따라야 합니다.

서명된 이미지가 OpenShift Container Registry에 이미 푸시되었다고 가정하면 다음 명령을 사용하여 서명을 읽을 수 있습니다.

GET /extensions/v2/<namespace>/<name>/signatures/<digest>

$ curl http://<user>:<token>@<registry_endpoint>:5000/extensions/v2/<namespace>/<name>/signatures/sha256:<digest>

<namespace> 는 OpenShift Container Platform 프로젝트 이름 또는 레지스트리 리포지토리 이름을 나타내고 <name> 은 이미지 리포지토리의 이름을 나타냅니다. 다이제스트 는 이미지의 SHA-256 체크섬을 나타냅니다.

지정된 이미지에 서명 데이터가 포함된 경우 위의 명령 출력에서 다음 JSON 응답을 생성해야 합니다.

{
  "signatures": [
  {
    "version": 2,
    "type":    "atomic",
    "name":    "sha256:4028782c08eae4a8c9a28bf661c0a8d1c2fc8e19dbaae2b018b21011197e1484@cddeb7006d914716e2728000746a0b23",
    "content": "<cryptographic_signature>"
  }
  ]
}

name 필드에는 고유해야 하며 <digest>@<name> 형식의 이미지 서명 이름이 포함되어 있습니다. <digest> 는 이미지 이름을 나타내고 <name> 은 서명의 이름입니다. 서명 이름은 32자여야 합니다. <cryptographic_signature> 는 컨테이너/이미지 라이브러리에 설명된 사양을 따라야 합니다.

레지스트리 구성 디렉터리를 통해 모든 OpenShift Container Platform 마스터 노드에 서명 저장소가 구성된 경우 OpenShift Container Platform은 이미지 서명을 자동으로 가져올 수 있습니다.

레지스트리 구성 디렉터리에는 다양한 레지스트리(원격 컨테이너 이미지를 저장하는 서버)와 여기에 저장된 콘텐츠에 대한 구성이 포함되어 있습니다. 단일 디렉터리를 사용하면 container/image의 모든 사용자가 공유할 수 있도록 각 명령의 명령줄 옵션으로 구성을 제공할 필요가 없습니다.

기본 레지스트리 구성 디렉터리는 /etc/containers/registries.d/default.yaml 파일에 있습니다.

모든 Red Hat 이미지에 대해 이미지 서명을 자동으로 가져오는 샘플 구성:

docker:
  registry.redhat.io:
    sigstore: https://registry.redhat.io/containers/sigstore 1

레지스트리 구성 디렉터리에 대한 자세한 내용은 레지스트리 구성 디렉터리를 참조하십시오.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext: 1
  containers:
  - name: sec-ctx-demo
    image: gcr.io/google-samples/node-hello:1.0

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000 1
  containers:
    - name: sec-ctx-demo
      image: gcr.io/google-samples/node-hello:1.0

이는 SELinux, fsGroup 및 Supplemental Groups에서 작동합니다. 자세한 내용은 볼륨 보안을 참조하십시오.

관리자가 관리자 그룹 외부의 사용자 또는 그룹이 액세스 권한을 갖는 사용자 또는 그룹을 허용하도록 허용해야 하는 경우도 있습니다. 이를 위해 다음을 수행할 수 있습니다.

먼저 서비스 계정을 만듭니다. 예를 들어 my project 프로젝트에서 서비스 계정 mysvcacct 를 생성하려면 다음을 수행합니다.

$ oc create serviceaccount mysvcacct -n myproject

그런 다음 권한 있는 SCC에 서비스 계정을 추가합니다.

$ oc adm policy add-scc-to-user privileged system:serviceaccount:myproject:mysvcacct

그런 다음 서비스 계정을 대신하여 리소스가 생성되고 있는지 확인합니다. 이를 위해 spec.serviceAccountName 필드를 서비스 계정 이름으로 설정합니다. 서비스 계정 이름을 비워 두면 기본 서비스 계정이 사용됩니다.

그런 다음 Pod의 컨테이너 중 하나 이상이 보안 컨텍스트에서 권한 있는 모드를 요청하는지 확인합니다.

이미지가 권한 있는 SCC에 대한 액세스 권한을 부여하지 않고 사전 할당된 UID로 실행하도록 클러스터의 보안을 완화하려면 다음을 수행합니다.

일부 컨테이너 이미지(예: postgres 및 redis)에는 루트 액세스 권한이 필요하며 볼륨이 소유되는 방법에 대한 특정 기대치가 있습니다. 이러한 이미지의 경우 anyuid SCC에 서비스 계정을 추가합니다.

$ oc adm policy add-scc-to-user anyuid system:serviceaccount:myproject:mysvcacct

레지스트리 배포에 PersistentVolume 및 PersistentVolumeClaim 오브젝트를 사용하는 영구 스토리지를 사용하는 것이 좋습니다. 테스트 중이며 oc adm registry 명령을 --mount-host 옵션과 함께 사용하려면 먼저 레지스트리에 대한 새 서비스 계정을 생성하여 권한 있는 SCC에 추가해야 합니다. 전체 지침은 관리자 가이드를 참조하십시오.

경우에 따라 이미지에 Docker에서 기본적으로 제공하지 않는 기능이 필요할 수 있습니다. SCC에 대해 검증할 Pod 사양에서 추가 기능을 요청하는 기능을 제공할 수 있습니다.

루트가 아닌 사용자와 함께 사용하는 경우 추가 기능이 필요한 파일에 setcap 명령을 사용하여 기능이 부여되었는지 확인해야 합니다. 예를 들어 이미지의 Dockerfile 에서 다음을 수행합니다.

setcap cap_net_raw,cap_net_admin+p /usr/bin/ping

또한 Docker에서 기본적으로 기능을 제공하는 경우 pod 사양을 수정하여 요청할 필요가 없습니다. 예를 들어 NET_RAW 는 기본적으로 제공되며 기능은 ping에 이미 설정되어 있어야 하므로 ping 을 실행하는 데 특별한 단계가 필요하지 않습니다 .

추가 기능을 제공하려면 다음을 수행합니다.

모든 사용자에 대해 anyuid SCC에 대한 액세스 권한을 부여하면 클러스터에 클러스터가 부여됩니다.

 $ oc adm policy add-scc-to-group anyuid system:authenticated

UID를 사전 할당하지 않고 컨테이너를 root로 실행할 수 없도록 클러스터를 수정하려면 모든 사용자에 대해 루트가 아닌 SCC 에 대한 액세스 권한을 부여합니다.

 $ oc adm policy add-scc-to-group nonroot system:authenticated

Pod에서 privileged, host access 또는 hostmount-anyuid 와 같은 권한 있는 SCC에 대한 액세스 권한을 부여하지 않고 Pod에서 hostPath 볼륨 플러그인을 사용할 수 있도록 클러스터의 보안을 완화하려면 다음 작업을 수행합니다.

이제 hostPath 볼륨을 요청하는 모든 Pod가 hostpath SCC에서 허용합니다.

SCC의 Priority 필드를 설정하여 허용 중인 SCC 정렬 순서를 제어할 수 있습니다. 정렬에 대한 자세한 내용은 SCC 우선순위 섹션을 참조하십시오.

SCC를 사용자 또는 그룹에 추가하기 전에 먼저 scc-review 옵션을 사용하여 사용자 또는 그룹이 포드를 만들 수 있는지 확인할 수 있습니다. 자세한 내용은 권한 부여 주제를 참조하십시오.

SCC는 프로젝트에 직접 부여되지 않습니다. 대신 SCC에 서비스 계정을 추가하고 포드에서 서비스 계정 이름을 지정하거나 지정되지 않은 경우 default 서비스 계정으로 실행합니다.

사용자에게 SCC를 추가하려면 다음을 수행합니다.

$ oc adm policy add-scc-to-user <scc_name> <user_name>

서비스 계정에 SCC를 추가하려면 다음을 수행합니다.

$ oc adm policy add-scc-to-user <scc_name> \
    system:serviceaccount:<serviceaccount_namespace>:<serviceaccount_name>

현재 서비스 계정이 속하는 프로젝트에 있는 경우 -z 플래그를 사용하고 <serviceaccount_name> 만 지정할 수 있습니다.

$ oc adm policy add-scc-to-user <scc_name> -z <serviceaccount_name>

그룹에 SCC를 추가하려면 다음을 수행합니다.

$ oc adm policy add-scc-to-group <scc_name> <group_name>

네임스페이스의 모든 서비스 계정에 SCC를 추가하려면 다음을 수행합니다.

$ oc adm policy add-scc-to-group <scc_name> \
    system:serviceaccounts:<serviceaccount_namespace>

Pod 예약은 클러스터 내 노드에 대한 새 Pod 배치를 결정하는 내부 프로세스입니다.

스케줄러 코드는 새 Pod가 생성될 때 해당 Pod를 감시하고 이를 호스팅하는 데 가장 적합한 노드를 확인할 수 있도록 깔끔하게 분리되어 있습니다. 그런 다음 마스터 API를 사용하여 Pod에 대한 바인딩(Pod와 노드의 바인딩)을 생성합니다.

OpenShift Container Platform에는 대부분의 사용자의 요구 사항을 충족하는 기본 스케줄러가 제공됩니다. 기본 스케줄러는 고유 툴과 사용자 지정 가능한 툴을 모두 사용하여 Pod에 가장 적합한 도구를 결정합니다.

기본 스케줄러에서 Pod 배치 및 사용 가능한 사용자 정의 매개 변수를 결정하는 방법에 대한 자세한 내용은 기본 예약을 참조하십시오.

새 Pod가 배치되는 위치를 추가로 제어해야 하는 경우 OpenShift Container Platform 고급 예약 기능을 사용하면 특정 노드 또는 특정 Pod와 함께 Pod를 시작(또는 기본 설정)하도록 Pod를 구성할 수 있습니다. 또한 고급 예약을 통해 Pod가 노드 또는 다른 Pod에 배치되지 않도록 할 수 있습니다.

고급 스케줄링에 대한 자세한 내용은 Advanced Scheduling 을 참조하십시오.

OpenShift Container Platform을 사용하면 Pod 사양을 편집하여 자체 또는 타사 스케줄러를 사용할 수도 있습니다.

자세한 내용은 Custom Scheduler를 참조하십시오.

기본 OpenShift Container Platform Pod 스케줄러는 클러스터 내의 노드에 대한 새 Pod 배치를 결정합니다. Pod에서 데이터를 읽고 구성된 정책에 따라 적합한 노드를 찾으려고 합니다. 이 스케줄러는 완전히 독립적이며 독립형/플러그형 솔루션으로 존재합니다. Pod를 수정하지 않고 Pod를 특정 노드에 연결하는 Pod 바인딩만 생성합니다.

기존 일반 스케줄러는 3단계 작업에서 Pod를 호스팅할 노드를 선택하는 기본 플랫폼 제공 스케줄러 엔진에 해당합니다.

사용 가능한 노드를 지정된 제약 조건 또는 요구 사항에 따라 필터링합니다. 이 작업은 서술자 라는 필터 함수 목록을 통해 각 노드를 실행하여 수행됩니다.

서술자 및 우선순위 를 선택하면 스케줄러에 대한 정책이 정의됩니다.

스케줄러 구성 파일은 스케줄러에서 고려할 서술자 및 우선순위를 지정하는 JSON 파일입니다.

스케줄러 정책 파일이 없으면 기본 구성 파일 /etc/origin/master/scheduler.json 이 적용됩니다.

{
    "apiVersion": "v1",
    "kind": "Policy",
    "predicates": [
        {
            "name": "NoVolumeZoneConflict"
        },
        {
            "name": "MaxEBSVolumeCount"
        },
        {
            "name": "MaxGCEPDVolumeCount"
        },
        {
            "name": "MaxAzureDiskVolumeCount"
        },
        {
            "name": "MatchInterPodAffinity"
        },
        {
            "name": "NoDiskConflict"
        },
        {
            "name": "GeneralPredicates"
        },
        {
            "name": "PodToleratesNodeTaints"
        },
        {
            "argument": {
                "serviceAffinity": {
                    "labels": [
                        "region"
                    ]
                }
            },
            "name": "Region"

         }
    ],
    "priorities": [
        {
            "name": "SelectorSpreadPriority",
            "weight": 1
        },
        {
            "name": "InterPodAffinityPriority",
            "weight": 1
        },
        {
            "name": "LeastRequestedPriority",
            "weight": 1
        },
        {
            "name": "BalancedResourceAllocation",
            "weight": 1
        },
        {
            "name": "NodePreferAvoidPodsPriority",
            "weight": 10000
        },
        {
            "name": "NodeAffinityPriority",
            "weight": 1
        },
        {
            "name": "TaintTolerationPriority",
            "weight": 1
        },
        {
            "argument": {
                "serviceAntiAffinity": {
                    "label": "zone"
                }
            },
            "name": "Zone",
            "weight": 2
        }
    ]
}

kind: "Policy"
version: "v1"
"predicates": [
        {
            "name": "PodFitsResources"
        },
        {
            "name": "NoDiskConflict"
        },
        {
            "name": "MatchNodeSelector"
        },
        {
            "name": "HostName"
        },
        {
            "argument": {
                "serviceAffinity": {
                    "labels": [
                        "region"
                    ]
                }
            },
            "name": "Region"
        }
    ],
    "priorities": [
        {
            "name": "LeastRequestedPriority",
            "weight": 1
        },
        {
            "name": "BalancedResourceAllocation",
            "weight": 1
        },
        {
            "name": "ServiceSpreadingPriority",
            "weight": 1
        },
        {
            "argument": {
                "serviceAntiAffinity": {
                    "label": "zone"
                }
            },
            "name": "Zone",
            "weight": 2
        }
    ]

서술자는 정규화되지 않은 노드를 필터링하는 규칙입니다.

OpenShift Container Platform에는 기본적으로 제공되는 몇 가지 서술자가 있습니다. 이러한 서술자 중 일부는 특정 매개변수를 제공하여 사용자 정의할 수 있습니다. 여러 개의 서술자를 결합하여 노드 필터링을 추가로 제공할 수도 있습니다.

{"name" : "NoVolumeZoneConflict"}

{"name" : "MaxEBSVolumeCount"}

{"name" : "MaxGCEPDVolumeCount"}

{"name" : "MatchInterPodAffinity"}

{"name" : "NoDiskConflict"}

{"name" : "PodToleratesNodeTaints"}

{"name" : "CheckVolumeBinding"}

{"name" : "CheckNodeCondition"}

{"name" : "PodToleratesNodeNoExecuteTaints"}

{"name" : "CheckNodeLabelPresence"}

{"name" : "checkServiceAffinity"}

{"name" : "MaxAzureDiskVolumeCount"}

{"name" : "PodFitsResources"}

{"name" : "PodFitsHostPorts"}

{"name" : "HostName"}

{"name" : "MatchNodeSelector"}

"predicates":[
      {
         "name":"<name>", 1
         "argument":{
            "serviceAffinity":{
               "labels":[
                  "<label>" 2
               ]
            }
         }
      }
   ],

        "name":"ZoneAffinity",
        "argument":{
            "serviceAffinity":{
                "labels":[
                    "rack"
                ]
            }
        }

"predicates":[
      {
         "name":"<name>", 1
         "argument":{
            "labelsPresence":{
               "labels":[
                  "<label>" 2
                ],
                "presence": true 3
            }
         }
      }
   ],

        "name":"RackPreferred",
        "argument":{
            "labelsPresence":{
                "labels":[
                    "rack",
                    "region"
                ],
                "presence": true
            }
        }

우선순위는 기본 설정에 따라 나머지 노드의 순위를 지정하는 규칙입니다.

스케줄러를 구성하기 위해 사용자 정의 우선순위 집합을 지정할 수 있습니다. OpenShift Container Platform에는 기본적으로 제공되는 몇 가지 우선순위가 있습니다. 특정 매개변수를 제공하여 기타 우선순위를 사용자 정의할 수 있습니다. 여러 우선순위를 결합하고 각각 서로 다른 가중치를 부여하여 우선순위 지정에 영향을 미칠 수 있습니다.

{"name" : "SelectorSpreadPriority", "weight" : 1}

{"name" : "InterPodAffinityPriority", "weight" : 1}

{"name" : "LeastRequestedPriority", "weight" : 1}

{"name" : "BalancedResourceAllocation", "weight" : 1}

{"name" : "NodePreferAvoidPodsPriority", "weight" : 10000}

{"name" : "NodeAffinityPriority", "weight" : 1}

{"name" : "TaintTolerationPriority", "weight" : 1}

{"name" : "EqualPriority", "weight" : 1}

{"name" : "MostRequestedPriority", "weight" : 1}

{"name" : "ImageLocalityPriority", "weight" : 1}

{"name" : "ServiceSpreadingPriority", "weight" : 1}

"priorities":[
    {
        "name":"<name>", 1
        "weight" : 1 2
        "argument":{
            "serviceAntiAffinity":{
                "label":[
                    "<label>" 3
                ]
            }
        }
    }
]

        "name":"RackSpread", 1
        "weight" : 1 2
        "argument":{
            "serviceAntiAffinity":{
                "label": "rack" 3
            }
        }

"priorities":[
    {
        "name":"<name>", 1
        "weight" : 1, 2
        "argument":{
            "labelPreference":{
                "label": "<label>", 3
                "presence": true 4
            }
        }
    }
]

OpenShift Container Platform 내에서 예약하는 중요 사용 사례 중 하나는 유연한 유사성 및 유사성 방지 정책을 지원하는 것입니다.

아래 구성은 스케줄러 정책 파일을 통해 지정하는 경우 기본 스케줄러 구성을 지정합니다.

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RegionZoneAffinity" 1
    argument:
      serviceAffinity: 2
        labels: 3
          - "region"
          - "zone"
priorities:
...
  - name: "RackSpread" 4
    weight: 1
    argument:
      serviceAntiAffinity: 5
        label: "rack" 6

아래의 모든 샘플 구성에서 서술자 및 우선순위 함수 목록은 지정된 사용 사례와 관련된 항목만 포함하도록 잘립니다. 실제로 완료된/유의미한 스케줄러 정책에는 위에 나열된 기본 서술자 및 우선순위 전부는 아니더라도 대부분이 포함되어야 합니다.

다음 예제에서는 세 가지 토폴로지 수준, 즉 region(유사성) → zone(유사성) → rack(유사성 방지)을 정의합니다.

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RegionZoneAffinity"
    argument:
      serviceAffinity:
        labels:
          - "region"
          - "zone"
priorities:
...
  - name: "RackSpread"
    weight: 1
    argument:
      serviceAntiAffinity:
        label: "rack"

다음 예제에서는 세 가지 토폴로지 수준, 즉 city(유사성) → building(유사성 방지) → room(유사성 방지)을 정의합니다.

kind: "Policy"
version: "v1"
predicates:
...
  - name: "CityAffinity"
    argument:
      serviceAffinity:
        labels:
          - "city"
priorities:
...
  - name: "BuildingSpread"
    weight: 1
    argument:
      serviceAntiAffinity:
        label: "building"
  - name: "RoomSpread"
    weight: 1
    argument:
      serviceAntiAffinity:
        label: "room"

다음 예제에서는 'region' 라벨이 정의된 노드만 사용하고 'zone' 라벨이 정의된 노드를 선호하는 정책을 정의합니다.

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RequireRegion"
    argument:
      labelsPresence:
        labels:
          - "region"
        presence: true
priorities:
...
  - name: "ZonePreferred"
    weight: 1
    argument:
      labelPreference:
        label: "zone"
        presence: true

다음 예제에서는 정적 및 구성 가능 서술자와 우선순위를 둘 다 결합합니다.

kind: "Policy"
version: "v1"
predicates:
...
  - name: "RegionAffinity"
    argument:
      serviceAffinity:
        labels:
          - "region"
  - name: "RequireRegion"
    argument:
      labelsPresence:
        labels:
          - "region"
        presence: true
  - name: "BuildingNodesAvoid"
    argument:
      labelsPresence:
        labels:
          - "building"
        presence: false
  - name: "PodFitsPorts"
  - name: "MatchNodeSelector"
priorities:
...
  - name: "ZoneSpread"
    weight: 2
    argument:
      serviceAntiAffinity:
        label: "zone"
  - name: "ZonePreferred"
    weight: 1
    argument:
      labelPreference:
        label: "zone"
        presence: true
  - name: "ServiceSpreadingPriority"
    weight: 1

예약 취소는 특정 정책에 따라 Pod를 제거하여 보다 적절한 노드에 Pod를 다시 예약할 수 있도록 합니다.

클러스터는 다양한 이유로 이미 실행 중인 Pod를 스케줄링하고 다시 스케줄링할 수 있습니다.

Descheduler는 제거된 Pod의 교체를 예약하지 않습니다. 제거된 Pod에 대해 스케줄러 에서 이 작업을 자동으로 수행합니다.

완전히 작동하는 클러스터에 중요하지만 마스터가 아닌 일반 클러스터 노드에서 실행되는 DNS와 같은 여러 핵심 구성 요소가 있다는 점에 유의해야 합니다. 구성 요소가 제거되면 클러스터가 제대로 작동하지 않을 수 있습니다. Descheduler가 이러한 Pod를 제거하지 않도록 하려면 scheduler.alpha.kubernetes.io/critical-pod 주석을 Pod 사양에 추가하여 Pod를 중요한 Pod로 구성합니다.

Descheduler 작업 및 Descheduler Pod는 기본적으로 생성된 kube-system 프로젝트에 생성됩니다.

Descheduler는 다음 유형의 Pod를 제거하지 않습니다.

다음 섹션에서는 Descheduler를 구성하고 실행하는 프로세스를 설명합니다.

Descheduler가 Pod에서 작동하는 데 필요한 권한을 구성하려면 다음을 수행합니다.

YAML 정책 파일의 전략에 의해 정의된 규칙을 위반하는 노드에서 Pod를 제거하도록 Descheduler를 구성할 수 있습니다. 그런 다음 특정 계획 전략을 적용하기 위해 해당 구성 맵을 사용하여 정책 파일의 경로와 작업 사양을 포함하는 구성 맵을 생성합니다.

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "RemoveDuplicates":
     enabled: false
  "LowNodeUtilization":
     enabled: true
     params:
       nodeResourceUtilizationThresholds:
         thresholds:
           "cpu" : 20
           "memory": 20
           "pods": 20
         targetThresholds:
           "cpu" : 50
           "memory": 50
           "pods": 50
         numberOfNodes: 3
  "RemovePodsViolatingInterPodAntiAffinity":
     enabled: true
  "RemovePodsViolatingNodeAffinity":
    enabled: true
    params:
      nodeAffinityType:
      - "requiredDuringSchedulingIgnoredDuringExecution"

Descheduler와 함께 사용할 수 있는 세 가지 기본 전략이 있습니다.

필요에 따라 전략과 관련된 매개변수를 구성하고 비활성화할 수 있습니다.

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "RemoveDuplicates":
     enabled: false 1

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "LowNodeUtilization":
     enabled: true
     params:
       nodeResourceUtilizationThresholds:
         thresholds: 1
           "cpu" : 20
           "memory": 20
           "pods": 20
         targetThresholds: 2
           "cpu" : 50
           "memory": 50
           "pods": 50
         numberOfNodes: 3 3

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "RemovePodsViolatingInterPodAntiAffinity": 1
     enabled: true

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "RemovePodsViolatingNodeAffinity": 1
    enabled: true
    params:
      nodeAffinityType:
      - "requiredDuringSchedulingIgnoredDuringExecution" 2

Descheduler 작업에서 참조할 수 있도록 kube-system 프로젝트에서 Descheduler 정책 파일에 대한 구성 맵을 생성합니다.

# oc create configmap descheduler-policy-configmap \
     -n kube-system --from-file=<path-to-policy-dir/policy.yaml> 1

Descheduler에 대한 작업 구성을 생성합니다.

apiVersion: batch/v1
kind: Job
metadata:
  name: descheduler-job
  namespace: kube-system
spec:
  parallelism: 1
  completions: 1
  template:
    metadata:
      name: descheduler-pod 1
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: "true" 2
    spec:
        containers:
        - name: descheduler
          image: registry.access.redhat.com/openshift3/ose-descheduler
          volumeMounts: 3
          - mountPath: /policy-dir
            name: policy-volume
          command:
          - "/bin/sh"
          - "-ec"
          - |
            /bin/descheduler --policy-config-file /policy-dir/policy.yaml 4
        restartPolicy: "Never"
        serviceAccountName: descheduler-sa 5
        volumes:
        - name: policy-volume
          configMap:
            name: descheduler-policy-configmap

정책 파일은 구성 맵에서 볼륨으로 마운트됩니다.

Pod에서 Descheduler를 작업으로 실행하려면 다음을 수행합니다.

# oc create -f <file-name>.yaml

예를 들면 다음과 같습니다.

# oc create -f descheduler-job.yaml

기본 스케줄러와 함께 여러 사용자 정의 스케줄러를 실행하고 각 Pod에 사용할 스케줄러를 구성할 수 있습니다.

특정 스케줄러를 사용하여 지정된 Pod를 예약하려면 해당 Pod 사양에서 스케줄러의 이름을 지정합니다.

클러스터에 사용자 지정 스케줄러를 포함하는 일반적인 프로세스에는 배포에 해당 이미지를 포함하여 이미지를 생성해야 합니다.

사용자 정의 스케줄러가 클러스터에 배포된 후 기본 스케줄러 대신 해당 스케줄러를 사용하도록 Pod를 구성할 수 있습니다.

클러스터 관리자는 Pod를 예약할 때 특정 역할을 가진 애플리케이션 개발자가 특정 노드를 대상으로 하지 못하도록 정책을 설정할 수 있습니다.

Pod 노드 제한 허용 컨트롤러는 라벨을 사용하여 지정된 노드 호스트에만 Pod를 배포하고 특정 역할이 없는 사용자가 nodeSelector 필드를 사용하여 Pod를 예약하지 않도록 합니다.

Pod 노드 제약 조건 승인 컨트롤러를 사용하여 Pod가 레이블을 할당하고 Pod 구성의 node Name 설정에서 이를 지정하여 지정된 노드 호스트에만 배포되도록 합니다.

노드 선택기를 사용하면 Pod가 특정 라벨이 있는 노드에만 배치되도록 할 수 있습니다. 클러스터 관리자는 Pod 노드 제약 조건 승인 컨트롤러를 사용하여 Pod /바인딩 권한이 없는 사용자가 노드 선택기를 사용하여 Pod 를 예약하지 못하도록 하는 정책을 설정할 수 있습니다.

마스터 구성 파일의 nodeSelectorLabelBlacklist 필드를 사용하면 특정 역할이 Pod 구성의 nodeSelector 필드에서 지정할 수 있는 라벨을 제어할 수 있습니다. pod/binding 권한 역할이 있는 사용자, 서비스 계정 및 그룹은 노드 선택기를 지정할 수 있습니다. pod/binding 권한이 없는 사용자는 nodeSelector LabelBlacklist에 표시되는 모든 라벨에 대해 nodeSelector 를 설정할 수 없습니다.

예를 들어 OpenShift Container Platform 클러스터는 두 지역에 분산된 데이터 센터 5개로 구성될 수 있습니다. 미국, us-east, us-central, us - west 및 아시아 태평양 지역(APAC), apac-east 및 apac-west 에서. 각 지역에 있는 각 노드는 그에 따라 레이블이 지정됩니다. 예를 들어 region: us-east 입니다.

클러스터 관리자는 애플리케이션 개발자가 지리적 위치에 가장 가까운 노드에만 포드를 배포해야 하는 인프라를 생성할 수 있습니다. 미국 데이터 센터를 슈퍼 지역으로 그룹화하는 노드 선택기를 생성할 수 있습니다. us 및 APAC 데이터 센터를 superregion: apac 로 그룹화할 수 있습니다.

데이터 센터당 리소스를 로드하도록 원하는 지역을 마스터 구성의 nodeSelectorLabelBlacklist 섹션에 추가할 수 있습니다. 그런 다음, 미국 내에 있는 개발자가 포드를 생성할 때마다 수퍼 영역인 us 레이블이 있는 지역 중 하나에 있는 노드에 배포됩니다. 개발자가 포드의 특정 리전을 대상으로 시도하는 경우(예 : region: us-east) 오류가 발생합니다. 포드에서 노드 선택기 없이 다시 시도하면 superregion: us가 프로젝트 수준 노드 선택기로 설정되어 있고 region : us -east의 레이블이 지정된 노드에 superregion: us라는 레이블이 지정되므로 여전히 대상 리전에 배포할 수 있습니다 .

Pod 노드 선택기 승인 컨트롤러를 사용하면 특정 프로젝트와 연결된 노드에 Pod를 강제 적용하고 해당 노드에서 Pod가 예약되지 않도록 할 수 있습니다.

Pod 노드 선택기 승인 컨트롤러는 Pod 에 지정된 프로젝트 및 노드 선택기의 라벨을 사용하여 Pod를 배치할 수 있는 위치를 결정합니다. 포드의 노드 선택기가 프로젝트의 라벨과 일치하는 경우에만 프로젝트와 연결된 노드에 새 포드가 배치됩니다.

Pod가 생성되면 노드 선택기가 Pod에 병합되므로 Pod 사양에 원래 사양에 포함된 라벨과 노드 선택기의 새 라벨이 포함됩니다. 아래 예제에서는 병합 효과를 보여줍니다.

Pod 노드 선택기 승인 컨트롤러를 사용하면 특정 프로젝트에서 허용되는 라벨 목록을 생성할 수도 있습니다. 이 목록은 개발자가 프로젝트에서 사용할 수 있는 레이블을 알 수 있도록 하는 허용 목록 역할을 하며 관리자에게 클러스터에서 레이블 지정을 더욱 효과적으로 제어할 수 있도록 합니다.

Pod 노드 선택기 승인 컨트롤러를 활성화하려면 다음을 수행합니다.

프로젝트 사양에 지정되지 않은 라벨을 사용하여 Pod를 생성하는 경우 Pod가 노드에 예약되지 않습니다.

예를 들어 여기서 레이블 env: production 은 프로젝트 사양에 없습니다.

nodeSelector:
 "env: production"
 "infra": "fedora",
 "os": "fedora"

노드 선택기 주석이 없는 노드가 있는 경우 해당 노드에 Pod가 예약됩니다.

클러스터에서 Pod 우선순위 및 선점을 활성화할 수 있습니다. Pod 우선 순위는 다른 Pod를 기준으로 Pod의 중요성을 나타내고 해당 우선 순위에 따라 Pod를 큐에 지정합니다. Pod 선점을 사용하면 클러스터에서 우선순위가 낮은 Pod를 제거하거나 선점할 수 있으므로 적절한 노드 Pod 우선순위에 사용 가능한 공간이 없는 경우 우선순위가 높은 Pod를 예약할 수 있습니다. 또한 노드의 Pod 예약 순서에 영향을 미칩니다.

우선순위 및 선점 기능을 사용하려면 Pod의 상대적 가중치를 정의하는 우선순위 클래스를 생성합니다. 그런 다음 Pod 사양의 우선순위 클래스를 참조하여 예약에 해당 값을 적용합니다.

선점은 스케줄러 구성 파일의 disablePreemption 매개변수로 제어되며 기본적으로 false 로 설정됩니다.

Pod 우선 순위 및 선점 기능이 활성화되면 스케줄러는 보류 중인 Pod를 우선 순위에 따라 주문하고 보류 중인 Pod는 예약 큐에서 우선 순위가 낮은 다른 보류 중인 Pod보다 먼저 배치됩니다. 그 결과 예약 요구 사항이 충족되는 경우 우선순위가 높은 Pod가 우선순위가 낮은 Pod보다 더 빨리 예약될 수 있습니다. Pod를 예약할 수 없는 경우에는 스케줄러에서 우선순위가 낮은 다른 Pod를 계속 예약합니다.

개발자가 Pod를 생성하면 Pod가 큐로 들어갑니다. Pod 우선 순위 및 선점 기능이 활성화되면 스케줄러는 대기열에서 Pod를 선택하고 노드에서 Pod를 예약하려고 합니다. 스케줄러가 노드에서 Pod의 지정된 요구 사항을 모두 충족하는 적절한 공간을 찾을 수 없는 경우 보류 중인 Pod에 대한 선점 논리가 트리거됩니다.

스케줄러가 노드에서 하나 이상의 Pod를 선점하면 우선순위가 높은 Pod 사양의 nominatedNodeName 필드가 nodename 필드와 함께 노드의 이름으로 설정됩니다. 스케줄러는 nominatedNodeName 필드를 사용하여 Pod용으로 예약된 리소스를 계속 추적하고 클러스터의 선점에 대한 정보도 사용자에게 제공합니다.

스케줄러에서 우선순위가 낮은 Pod를 선점한 후에는 Pod의 정상 종료 기간을 따릅니다. 스케줄러에서 우선순위가 낮은 Pod가 종료되기를 기다리는 동안 다른 노드를 사용할 수 있게 되는 경우 스케줄러는 해당 노드에서 우선순위가 더 높은 Pod를 예약할 수 있습니다. 결과적으로 Pod 사양의 nominatedNodeName 필드 및 nodeName 필드가 다를 수 있습니다.

또한 스케줄러가 노드의 Pod를 선점하고 종료되기를 기다리고 있는 상태에서 보류 중인 Pod보다 우선순위가 높은 Pod를 예약해야 하는 경우, 스케줄러는 우선순위가 더 높은 Pod를 대신 예약할 수 있습니다. 이러한 경우 스케줄러는 보류 중인 Pod의 nominatedNodeName을 지워 해당 Pod를 다른 노드에 사용할 수 있도록 합니다.

선점을 수행해도 우선순위가 낮은 Pod가 노드에서 모두 제거되는 것은 아닙니다. 스케줄러는 우선순위가 낮은 Pod의 일부를 제거하여 보류 중인 Pod를 예약할 수 있습니다.

스케줄러는 노드에서 보류 중인 Pod를 예약할 수 있는 경우에만 해당 노드에서 Pod 선점을 고려합니다.

Pod 우선순위 및 선점은 예약하기 위해 Pod에 우선순위를 할당합니다. 스케줄러는 우선순위가 높은 Pod를 예약하기 위해 우선순위가 낮은 Pod를 선점(evict)합니다.

우선순위 클래스 오브젝트를 생성하고 Pod 사양에서 priority ClassName을 사용하여 Pod를 우선순위에 연결하여 우선순위 및 선점을 적용합니다.

apiVersion: scheduling.k8s.io/v1beta1
kind: PriorityClass
metadata:
  name: high-priority 1
value: 1000000 2
globalDefault: false 3
description: "This priority class should be used for XYZ service pods only." 4

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority 1

우선순위 및 선점을 사용하도록 클러스터를 구성하려면 다음을 수행합니다.

Pod 우선순위 및 선점 기능을 비활성화할 수 있습니다.

기능이 비활성화되면 기존 Pod는 우선순위 필드를 유지하지만 선점은 비활성화되고 우선순위 필드는 무시됩니다. 기능이 비활성화되면 새 Pod에 우선순위 클래스 이름을 설정할 수 없습니다.

클러스터의 선점을 비활성화하려면 다음을 수행합니다.

고급 예약에는 Pod가 특정 노드에서 실행되거나 특정 노드에서 실행되도록 Pod를 구성해야 합니다.

OpenShift Container Platform에서 적절한 방식으로 Pod를 자동으로 배치하므로 일반적으로 고급 예약은 필요하지 않습니다. 예를 들어 기본 스케줄러는 노드에 Pod를 균등하게 배포하고 노드에서 사용 가능한 리소스를 고려합니다. 그러나 포드가 배치되는 위치를 추가로 제어할 수 있습니다.

Pod가 더 빠른 디스크 속도로 머신에 있어야 하거나 해당 시스템에 배치되지 않거나 Pod를 통신할 수 있도록 두 가지 서비스의 포드를 배치해야 하는 경우 고급 예약을 사용하여 이러한 작업을 수행할 수 있습니다.

적절한 새 Pod가 전용 노드 그룹에 예약되고 다른 새 Pod가 해당 노드에 예약되지 않도록 하려면 필요에 따라 이러한 방법을 결합할 수 있습니다.

클러스터에서 고급 예약을 호출하는 방법에는 여러 가지가 있습니다.

노드 유사성 은 스케줄러에서 Pod를 배치할 수 있는 위치를 결정하는 데 사용하는 규칙 집합입니다. 규칙은 노드의 사용자 정의 라벨과 Pod에 지정된 라벨 선택기를 사용하여 정의됩니다. 노드 유사성을 사용하면 Pod 에서 배치할 수 있는 노드 그룹에 대한 선호도(또는 유사성 방지)를 지정할 수 있습니다. 노드는 배치를 제어할 수 없습니다.

예를 들어 특정 CPU 또는 특정 가용성 영역이 있는 노드에서만 실행하도록 Pod를 구성할 수 있습니다.

노드 유사성 규칙에는 필수 및 기본 두 가지의 유형이 있습니다.

노드에 Pod를 예약하려면 먼저 필수 규칙을 충족해야 합니다. 기본 규칙은 규칙이 충족되는 경우 스케줄러가 규칙을 적용하려고 하지만 반드시 적용되는 것은 아닙니다.

Pod 사양 파일을 통해 노드 유사성을 구성합니다. 필수 규칙, 기본 규칙 또는 둘 다 지정할 수 있습니다. 둘 다 지정하는 경우 노드는 먼저 필수 규칙을 충족한 다음 기본 규칙을 충족하려고 합니다.

다음 예제는 키가 e2e-az-NorthSouth이고 값이 e2e-az- North 또는 e2e-az-South 인 레이블이 있는 노드에 Pod를 배치해야 하는 규칙이 있는 Pod 사양입니다.

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity: 1
      requiredDuringSchedulingIgnoredDuringExecution: 2
        nodeSelectorTerms:
        - matchExpressions:
          - key: e2e-az-NorthSouth 3
            operator: In 4
            values:
            - e2e-az-North 5
            - e2e-az-South 6
  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod

다음 예제는 Pod에 대해 키가 e2e-az-EastWest이고 값이 e2e-az-East 또는 e2e-az-West인 라벨이 있는 노드를 선호하는 기본 규칙이 있는 노드 사양입니다.

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity: 1
      preferredDuringSchedulingIgnoredDuringExecution: 2
      - weight: 1 3
        preference:
          matchExpressions:
          - key: e2e-az-EastWest 4
            operator: In 5
            values:
            - e2e-az-East 6
            - e2e-az-West 7
  containers:
  - name: with-node-affinity
    image: docker.io/ocpqe/hello-pod

명시적인 노드 유사성 방지 개념은 없지만 NotIn 또는 DoesNotExist 연산자를 사용하여 해당 동작을 복제합니다.

다음 예제에서는 노드 유사성을 보여줍니다.

Pod 유사성 및 Pod 유사성 방지를 사용하면 다른 Pod와 관련하여 Pod를 배치해야 하는 방법에 대한 규칙을 지정할 수 있습니다. 규칙은 노드의 사용자 정의 라벨과 Pod에 지정된 라벨 선택기를 사용하여 정의됩니다. Pod 유사성/유사성 방지를 사용하면 Pod 에서 배치할 수 있는 Pod 그룹에 유사성(또는 유사성 방지)을 지정할 수 있습니다. 노드는 배치를 제어할 수 없습니다.

예를 들어 유사성 규칙을 사용하여 서비스 내에서 또는 다른 서비스의 Pod와 관련하여 Pod를 분배하거나 패키징할 수 있습니다. 유사성 방지 규칙을 사용하면 특정 서비스의 Pod가 첫 번째 서비스의 Pod 성능을 방해하는 것으로 알려진 다른 서비스의 Pod와 동일한 노드에 예약되지 않도록 할 수 있습니다. 또는 서비스의 Pod를 노드 또는 가용성 영역에 분배하여 관련 오류를 줄일 수 있습니다.

Pod 유사성/유사성 방지를 사용하면 다른 Pod의 라벨에 따라 Pod를 예약할 수 있는 노드를 제한할 수 있습니다. 레이블 은 키/값 쌍입니다.

Pod 유사성 규칙에는 필수 및 기본 두 가지의 유형이 있습니다.

노드에 Pod를 예약하려면 먼저 필수 규칙을 충족해야 합니다. 기본 규칙은 규칙이 충족되는 경우 스케줄러가 규칙을 적용하려고 하지만 반드시 적용되는 것은 아닙니다.

Pod 사양 파일을 통해 Pod 유사성/유사성 방지를 구성합니다. 필수 규칙, 기본 규칙 또는 둘 다 지정할 수 있습니다. 둘 다 지정하는 경우 노드는 먼저 필수 규칙을 충족한 다음 기본 규칙을 충족하려고 합니다.

다음 예는 Pod 유사성 및 유사성 방지용으로 구성된 Pod 사양을 보여줍니다.

이 예제에서 Pod 유사성 규칙은 노드에 이미 실행 중인 Pod가 한 개 이상 있고 키가 security이고 값이 S1인 라벨이 있는 경우에만 노드에 Pod를 예약할 수 있음을 나타냅니다. Pod 유사성 방지 규칙은 노드에서 이미 Pod를 실행 중이고 키가 security이고 값이 S2인 라벨이 있는 경우 Pod를 노드에 예약하지 않는 것을 선호함을 나타냅니다.

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity: 1
      requiredDuringSchedulingIgnoredDuringExecution: 2
      - labelSelector:
          matchExpressions:
          - key: security 3
            operator: In 4
            values:
            - S1 5
        topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-antiaffinity
spec:
  affinity:
    podAntiAffinity: 1
      preferredDuringSchedulingIgnoredDuringExecution: 2
      - weight: 100  3
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security 4
              operator: In 5
              values:
              - S2
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: docker.io/ocpqe/hello-pod