REST API와의 모든 통신 채널은 물론 etcd 및 API 서버 등의 마스터 구성 요소 간 통신 채널은 TLS로 보호됩니다. TLS는 X.509 서버 인증서 및 공개 키 인프라를 사용하여 서버의 강력한 암호화, 데이터 무결성 및 인증을 제공합니다. 기본적으로 OpenShift Container Platform의 각 배포에 대해 새로운 내부 PKI가 생성됩니다. 내부 PKI는 2048비트 RSA 키와 SHA-256 서명을 사용합니다. 공용 호스트에 대한 사용자 지정 인증서 도 지원됩니다.

OpenShift Container Platform은 Golang의 crypto/tls 표준 라이브러리 구현을 사용하며 외부 암호화 및 TLS 라이브러리를 사용하지 않습니다. 또한 클라이언트는 GSSAPI 인증 및 OpenPGP 서명을 위한 외부 라이브러리에 의존합니다. GSSAPI는 일반적으로 MIT Kerberos 또는 Heimdal Kerberos에서 제공하며, 둘 다 OpenSSL의 libcrypto를 사용합니다. OpenPGP 서명 확인은 libgpgme 및 GnuPG에서 처리합니다.

안전하지 않은 버전의 SSL 2.0 및 SSL 3.0은 지원되지 않으며 사용할 수 없습니다. OpenShift Container Platform 서버 및 oc 클라이언트는 기본적으로 TLS 1.2만 제공합니다. TLS 1.0 및 TLS 1.1은 서버 구성에서 활성화할 수 있습니다. 서버와 클라이언트 모두 인증된 암호화 알고리즘과 완벽한 전달 보안을 갖춘 최신 암호화 제품군을 선호합니다. RC4, 3DES, MD5와 같이 더 이상 사용되지 않고 안전하지 않은 알고리즘이 있는 암호화 제품군이 비활성화됩니다. 일부 내부 클라이언트(예: LDAP 인증)는 TLS 1.0에서 1.2로 설정이 덜 제한되고 더 많은 암호 제품군이 활성화되어 있습니다.

OpenShift Container Platform 서버 및 oc 클라이언트에서 활성화된 암호화 제품군의 다음 목록은 기본으로 정렬됩니다.

OpenShift Container Platform 내에서 Kubernetes는 컨테이너 또는 호스트 집합에서 컨테이너화된 애플리케이션을 관리하고 배포, 유지 관리 및 애플리케이션 확장에 대한 메커니즘을 제공합니다. 컨테이너화된 애플리케이션을 인스턴스화 및 실행합니다. Kubernetes 클러스터는 하나 이상의 마스터와 노드 집합으로 구성됩니다.

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

마스터는 API 서버, 컨트롤러 관리자 서버 및 etcd를 포함하여 컨트롤 플레인 구성 요소가 포함된 호스트 또는 호스트입니다. 마스터는 Kubernetes 클러스터에서 노드를 관리하고 해당 노드에서 실행되도록 포드를 예약합니다.

2.1.2.1. 컨트롤 플레인 정적 포드

핵심 컨트롤 플레인 구성 요소, 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 볼륨이 정의되어 있습니다.

/etc/origin/master	모든 인증서, 구성 파일 및 admin.kubeconfig 파일을 포함합니다.
/var/lib/origin	바이너리의 볼륨 및 잠재적인 코어 덤프를 포함합니다.
/etc/origin/cloudprovider	클라우드 공급자별 구성(AWS, Azure 등)을 포함합니다.
/usr/libexec/kubernetes/kubelet-plugins	추가 타사 볼륨 플러그인을 포함합니다.
/etc/origin/kubelet-plugins	시스템 컨테이너용 추가 타사 볼륨 플러그인을 포함합니다.

정적 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

노드는 컨테이너를 위한 런타임 환경을 제공합니다. Kubernetes 클러스터의 각 노드에는 마스터에서 관리하는 데 필요한 서비스가 있습니다. 노드에는 컨테이너 런타임, kubelet 및 서비스 프록시를 포함하여 Pod를 실행하는 데 필요한 서비스도 있습니다.

OpenShift Container Platform은 클라우드 공급자, 물리적 시스템 또는 가상 시스템에서 노드를 생성합니다. Kubernetes는 해당 노드를 나타내는 노드 오브젝트 와 상호 작용합니다. 마스터는 노드 오브젝트의 정보를 사용하여 상태 점검에서 노드를 검증합니다. 노드는 상태 점검을 통과할 때까지 무시되며 마스터는 노드가 유효할 때까지 노드를 계속 확인합니다. Kubernetes 설명서 에는 노드 상태 및 관리에 대한 자세한 정보가 있습니다.

관리자는 CLI를 사용하여 OpenShift Container Platform 인스턴스에서 노드를 관리할 수 있습니다. 노드 서버를 시작할 때 전체 구성 및 보안 옵션을 정의하려면 전용 노드 구성 파일을 사용합니다.

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.1.3.4. 노드 부트스트랩

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

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

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

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

노드 부트스트랩 워크플로

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

1. 기본적으로 클러스터 설치 중에 노드 부트스트랩에 사용하기 위해 clusterrole, clusterrolebinding 및 serviceaccount 오브젝트 세트가 생성됩니다.

   • system:node-bootstrapper 클러스터 역할은 노드 부트스트랩 중에 CSR(인증서 서명 요청)을 생성하는 데 사용됩니다.

     $ oc describe clusterrole.authorization.openshift.io/system:node-bootstrapper

     출력 예

     Name:			system:node-bootstrapper
     Created:		17 hours ago
     Labels:			kubernetes.io/bootstrapping=rbac-defaults
     Annotations:		authorization.openshift.io/system-only=true
     			openshift.io/reconcile-protect=false
     Verbs			Non-Resource URLs	Resource Names	API Groups		Resources
     [create get list watch]	[]			[]		[certificates.k8s.io]	[certificatesigningrequests]

   • 다음 node-bootstrapper 서비스 계정이 openshift-infra 프로젝트에 생성됩니다.

     $ oc describe sa node-bootstrapper -n openshift-infra

     출력 예

     Name:                node-bootstrapper
     Namespace:           openshift-infra
     Labels:              <none>
     Annotations:         <none>
     Image pull secrets:  node-bootstrapper-dockercfg-f2n8r
     Mountable secrets:   node-bootstrapper-token-79htp
                          node-bootstrapper-dockercfg-f2n8r
     Tokens:              node-bootstrapper-token-79htp
                          node-bootstrapper-token-mqn2q
     Events:              <none>

   • 다음 system:node-bootstrapper 클러스터 역할 바인딩은 노드 부트스트랩자 클러스터 역할 및 서비스 계정에 사용됩니다.

     $ oc describe clusterrolebindings system:node-bootstrapper

     출력 예

     Name:			system:node-bootstrapper
     Created:		17 hours ago
     Labels:			<none>
     Annotations:		openshift.io/reconcile-protect=false
     Role:			/system:node-bootstrapper
     Users:			<none>
     Groups:			<none>
     ServiceAccounts:	openshift-infra/node-bootstrapper
     Subjects:		<none>
     Verbs			Non-Resource URLs	Resource Names	API Groups		Resources
     [create get list watch]	[]			[]		[certificates.k8s.io]	[certificatesigningrequests]

2. 클러스터 설치 중에 openshift-ansible 설치 프로그램은 OpenShift Container Platform 인증 기관과 다양한 다른 인증서, 키 및 kubeconfig 파일을 /etc/origin/master 디렉터리에 생성합니다. 두 개의 참고 파일은 다음과 같습니다.

   /etc/origin/master/admin.kubeconfig	system:admin 사용자를 사용합니다.
   /etc/origin/master/bootstrap.kubeconfig	마스터 이외의 노드 부트스트랩 노드에 사용됩니다.

   1. 설치 프로그램이 다음과 같이 node- bootstrapper 서비스 계정을 사용하는 경우 /etc/origin/master/bootstrap.kubeconfig 가 생성됩니다.

      $ oc --config=/etc/origin/master/admin.kubeconfig \
          serviceaccounts create-kubeconfig node-bootstrapper \
          -n openshift-infra

   2. 마스터 노드에서 /etc/origin/master/admin.kubeconfig 는 부트스트랩 파일로 사용되며 /etc/origin/node/boostrap.kubeconfig 에 복사됩니다. 다른 비마스터 노드에서 /etc/origin/master/bootstrap.kubeconfig 파일이 각 노드 호스트의 /etc/origin/node/boostrap.kubeconfig 의 다른 모든 노드에 복사됩니다.

   3. 그런 다음 /etc/origin/master/bootstrap.kubeconfig 가 다음과 같이 --bootstrap-kubeconfig 플래그를 사용하여 kubelet에 전달됩니다.

      --bootstrap-kubeconfig=/etc/origin/node/bootstrap.kubeconfig

3. kubelet은 제공된 /etc/origin/node/bootstrap.kubeconfig 파일로 처음 시작됩니다. 내부적으로 초기 연결 후 kubelet은 CSR(인증서 서명 요청)을 생성하여 마스터로 보냅니다.

4. CSR은 컨트롤러 관리자(특히 인증서 서명 컨트롤러)를 통해 확인하고 승인합니다. 승인되면 kubelet 클라이언트 및 서버 인증서가 /etc/origin/node/ceritificates 디렉터리에 생성됩니다. 예를 들면 다음과 같습니다.

   # ls -al /etc/origin/node/certificates/

   출력 예

   total 12
   drwxr-xr-x. 2 root root  212 Jun 18 21:56 .
   drwx------. 4 root root  213 Jun 19 15:18 ..
   -rw-------. 1 root root 2826 Jun 18 21:53 kubelet-client-2018-06-18-21-53-15.pem
   -rw-------. 1 root root 1167 Jun 18 21:53 kubelet-client-2018-06-18-21-53-45.pem
   lrwxrwxrwx. 1 root root   68 Jun 18 21:53 kubelet-client-current.pem -> /etc/origin/node/certificates/kubelet-client-2018-06-18-21-53-45.pem
   -rw-------. 1 root root 1447 Jun 18 21:56 kubelet-server-2018-06-18-21-56-52.pem
   lrwxrwxrwx. 1 root root   68 Jun 18 21:56 kubelet-server-current.pem -> /etc/origin/node/certificates/kubelet-server-2018-06-18-21-56-52.pem

5. CSR 승인 후 node.kubeconfig 파일이 /etc/origin/node/node.kubeconfig 에 생성됩니다.
6. kubelet은 /etc/origin/node/node.kubeconfig 파일과 /etc/origin/node/certificates/ 디렉터리의 인증서로 다시 시작됩니다. 이 인증서는 클러스터에 참여할 준비가 되었습니다.

노드 설정 워크플로

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

1. 처음에 노드의 kubelet은 노드 프로비저닝 시 생성된 /etc/origin/ node/ 디렉터리에 부트스트랩 구성 파일 bootstrap-node -config.yaml 로 시작됩니다.
2. 각 노드에서 노드 서비스 파일은 /usr/local/bin/ 디렉터리에 있는 로컬 스크립트 openshift-node 를 사용하여 제공된 bootstrap-node-config.yaml 을 사용하여 kubelet을 시작합니다.
3. 각 마스터에서 /etc/origin/node/pods 디렉터리에는 마스터에서 정적 포드로 생성되는 apiserver,controller 및 etcd 의 Pod 매니페스트가 포함되어 있습니다.

4. 클러스터 설치 중에 각 노드에 동기화 Pod를 생성하는 동기화 DaemonSet이 생성됩니다. 동기화 포드는 /etc/sysconfig/atomic-openshift-node 파일의 변경 사항을 모니터링합니다. BOOTSTRAP_CONFIG_NAME 이 설정되도록 특히 감시합니다. BOOTSTRAP_CONFIG_NAME 은 openshift-ansible 설치 프로그램에서 설정하며 노드가 속하는 노드 구성 그룹에 따라 ConfigMap의 이름입니다.

   기본적으로 설치 프로그램은 다음 노드 구성 그룹을 생성합니다.

   • node-config-master
   • node-config-infra
   • node-config-compute
   • node-config-all-in-one
   • node-config-master-infra

   각 그룹의 ConfigMap은 openshift-node 프로젝트에 생성됩니다.

5. 동기화 Pod는 BOOTSTRAP_CONFIG_NAME 에 설정된 값을 기반으로 적절한 ConfigMap을 추출합니다.
6. 동기화 Pod는 ConfigMap 데이터를 kubelet 구성으로 변환하고 해당 노드 호스트에 대한 /etc/origin/node/node-config.yaml 을 생성합니다. 이 파일(또는 파일의 초기 생성)을 변경하면 kubelet이 다시 시작됩니다.

노드 구성 수정

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

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

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

OpenShift Container Platform은 Docker Hub, 타사가 실행하는 프라이빗 레지스트리, 통합된 OpenShift Container Platform 레지스트리 등 컨테이너 이미지 레지스트리 API를 이미지의 소스로 구현하는 모든 서버를 활용할 수 있습니다.

OpenShift Container Platform은 필요에 따라 새 이미지 리포지토리를 자동으로 프로비저닝하는 기능을 추가하는 OCR(OpenShift Container Registry )이라는 통합 컨테이너 이미지 레지스트리를 제공합니다. 이를 통해 사용자는 애플리케이션 빌드에 결과 이미지를 푸시할 수 있는 기본 제공 위치를 제공합니다.

새 이미지를 OCR로 내보낼 때마다 레지스트리는 OpenShift Container Platform에 새 이미지에 대해 알리고 네임스페이스, 이름, 이미지 메타데이터와 같은 해당 이미지에 대한 모든 정보를 전달합니다. 다른 OpenShift Container Platform은 새 이미지에 반응하여 새 빌드 및 배포를 생성합니다.

OCR은 빌드 및 배포 통합 없이 컨테이너 이미지 레지스트리 역할을 하는 독립 실행형 구성 요소로도 배포할 수 있습니다. 자세한 내용은 OpenShift Container Registry 독립 실행형 배포 설치를 참조하십시오.

OpenShift Container Platform은 타사 레지스트리의 이미지를 사용하여 컨테이너를 생성할 수 있지만 이러한 레지스트리가 통합된 OpenShift Container Platform 레지스트리와 동일한 이미지 알림 지원을 제공하지는 않습니다. 이 경우 OpenShift Container Platform은 이미지 스트림 생성 시 원격 레지스트리에서 태그를 가져옵니다. oc import-image <stream>을 실행하여 가져온 태그를 간단하게 업데이트할 수 있습니다. 새 이미지가 감지되면 이전에 설명된 빌드 및 배포에 대한 응답이 발생합니다.

엔터프라이즈급 컨테이너 이미지 레지스트리가 필요한 경우 Red Hat Quay는 호스팅 서비스와 자체 데이터 센터 또는 클라우드 환경에 설치할 수있는 소프트웨어로 사용할 수 있습니다. Red Hat Quay의 고급 레지스트리에는 리전 복제, 이미지 스캔 및 이미지 롤백 기능이 포함되어 있습니다.

Quay.io 사이트를 방문하여 호스팅된 Quay 레지스트리 계정을 설정합니다. 그런 다음 Quay 튜토리얼 에 따라 Quay 레지스트리에 로그인하고 이미지 관리를 시작합니다. 또는 고유한 Red Hat Quay 레지스트리 설정에 대한 정보는 Red Hat Quay로 시작하기 를 참조하십시오.

원격 컨테이너 이미지 레지스트리와 마찬가지로 OpenShift Container Platform에서 Red Hat Quay 레지스트리에 액세스할 수 있습니다. Red Hat Quay에 보안 레지스트리로 액세스하기 위한 자격 증명을 설정하는 방법을 알아보려면 다른 보안 레지스트리의 참조 이미지에 포드 허용을 참조하십시오.

Red Hat Container Catalog를 통해 사용할 수 있는 모든 컨테이너 이미지는 이미지 레지스트리인 registry.access.redhat.com 에 호스팅됩니다. OpenShift Container Platform 3.11 Red Hat Container Catalog를 registry.access.redhat.com에서 registry. redhat.io 로 이동했습니다.

새 레지스트리 registry.redhat.io 는 OpenShift Container Platform의 이미지 및 호스팅 콘텐츠에 액세스할 수 있는 인증이 필요합니다. 새 레지스트리로 마이그레이션한 후 기존 레지스트리를 일정 기간 동안 사용할 수 있습니다.

새 레지스트리는 다음과 같은 방법으로 인증에 표준 OAuth 메커니즘을 사용합니다.

사용자 이름 및 암호 또는 인증 토큰 중 하나의 자격 증명으로 Docker 로그인을 사용하여 새 레지스트리의 콘텐츠에 액세스할 수 있습니다.

모든 이미지 스트림은 새 레지스트리를 가리킵니다. 새 레지스트리에는 액세스에 대한 인증이 필요하므로 OpenShift 네임스페이스에 imagestreamsecret 이라는 새 시크릿이 있습니다.

다음 두 위치에 인증 정보를 배치해야 합니다.

새 레지스트리에 액세스하려면 다음을 수행합니다.

OpenShift Container Platform 웹 콘솔은 웹 브라우저에서 액세스할 수 있는 사용자 인터페이스입니다. 개발자는 웹 콘솔을 사용하여 프로젝트의 콘텐츠를 시각화, 탐색 및 관리할 수 있습니다.

웹 콘솔은 마스터에서 포드로 실행됩니다. Pod에서는 웹 콘솔을 실행하는 데 필요한 정적 환경을 제공합니다. 관리자는 확장 기능을 사용하여 웹 콘솔을 사용자 지정할 수도 있습니다. 그러면 웹 콘솔이 로드될 때 스크립트를 실행하고 사용자 지정 스타일시트를 로드할 수 있습니다.

브라우저에서 웹 콘솔에 액세스하면 먼저 필요한 모든 정적 자산을 로드합니다. 그런 다음 openshift start 옵션 --public-master에서 정의한 값을 사용하거나 openshift - web- console 네임스페이스에 정의된 webconsole-config 구성 맵의 관련 매개변수 masterPublicURL 에서 OpenShift Container Platform API에 요청합니다. 웹 콘솔에서는 WebSockets를 사용하여 API 서버와의 지속적인 연결을 유지하고 사용 가능한 즉시 업데이트된 정보를 받습니다.

그림 2.3. 웹 콘솔 요청 아키텍처

웹 콘솔에 대해 구성된 호스트 이름과 IP 주소는 브라우저에서 요청을 교차 원본으로 간주하는 경우에도 API 서버에 안전하게 액세스하도록 허용 목록에 표시됩니다. 다른 호스트 이름을 사용하여 웹 애플리케이션에서 API 서버에 액세스하려면 openshift start 또는 관련 마스터 구성 파일 corsAllowedOrigin s에서 --cors-allowed-origin s 옵션을 지정하여 해당 호스트 이름을 허용해야 합니다.

corsAllowedOrigins 매개 변수는 구성 필드에 의해 제어됩니다. 해당 값에 고정 또는 이스케이핑이 수행되지 않습니다. 다음은 호스트 이름 및 이스케이프 지점을 고정할 수 있는 방법의 예입니다.

corsAllowedOrigins:
- (?i)//my\.subdomain\.domain\.com(:|\z)

웹 콘솔의 도움말 아이콘에서 CLI 다운로드에 액세스할 수 있습니다.

클러스터 관리자는 이러한 링크를 추가로 사용자 지정할 수 있습니다.

OpenShift Container Platform 에 대해 테스트된 통합을 검토합니다.

로그인 후 웹 콘솔에서는 현재 선택한 프로젝트에 대한 개요를 개발자에게 제공합니다.

그림 2.4. 웹 콘솔 프로젝트 개요

Java 이미지를 기반으로 하는 Pod의 경우 웹 콘솔은 관련된 통합 구성 요소를 보고 관리하기 위해 hawt.io기반 JVM 콘솔에 대한 액세스도 노출합니다. 컨테이너에 jolokia 라는 포트가 있는 경우 연결 링크가 Browse → Pods 페이지의 Pod 세부 정보에 표시됩니다.

그림 2.5. JVM 콘솔에 연결되는 Pod

JVM 콘솔에 연결하면 연결된 포드와 관련된 구성 요소에 따라 다른 페이지가 표시됩니다.

그림 2.6. JVM 콘솔

다음 페이지를 사용할 수 있습니다.

StatefulSet 컨트롤러는 Pod에 고유한 ID를 제공하고 배포 및 스케일링 순서를 결정합니다. StatefulSet 는 고유한 네트워크 식별자, 영구저장장치, 정상 배포 및 확장, 정상적인 삭제 및 종료에 유용합니다.

그림 2.7. OpenShift Container Platform의 StatefulSet

OpenShift Container Platform 애플리케이션의 기본 단위는 컨테이너라고 합니다. Linux 컨테이너 기술은 실행 중인 프로세스를 격리하는 데 필요한 간단한 메커니즘으로, 이를 통해 실행 중인 프로세스는 지정된 리소스하고만 상호 작용하도록 제한됩니다.

많은 애플리케이션 인스턴스는 서로의 프로세스, 파일, 네트워크 등을 보지 않으며 단일 호스트의 컨테이너에서 실행될 수 있습니다. 컨테이너를 임의의 워크로드에 사용할 수는 있지만 일반적으로 각 컨테이너는 웹 서버나 데이터베이스 같은 단일 서비스(흔히 “마이크로 서비스”라고 함)를 제공합니다.

Linux 커널은 수년간 컨테이너 기술을 위한 기능을 통합해 왔습니다. 최근에 Docker 프로젝트는 호스트의 Linux 컨테이너용 편리한 관리 인터페이스를 개발했습니다. OpenShift Container Platform 및 Kubernetes는 다중 호스트 설치에서 Docker 형식의 컨테이너를 오케스트레이션하는 기능을 추가합니다.

OpenShift Container Platform을 사용할 때 Docker CLI 또는 서비스와 직접 상호 작용하지는 않지만 OpenShift Container Platform에서 역할과 애플리케이션이 컨테이너 내에서 작동하는 방식을 이해하는 데 필요한 기능 및 용어를 이해하는 것이 중요합니다. Docker RPM은 RHEL 7과 CentOS 및 Fedora의 일부로 제공되므로 OpenShift Container Platform과 별도로 시험할 수 있습니다. 가이드 소개는 Red Hat Systems의 Docker Formatted Container Images 문서를 참조하십시오.

OpenShift Container Platform의 컨테이너는 Docker 형식의 컨테이너 이미지를 기반으로 합니다. 이미지는 단일 컨테이너를 실행하는 데 필요한 모든 요구 사항과 필요성 및 기능에 대해 설명하는 메타데이터가 포함되어 있는 바이너리입니다.

이미지는 패키징 기술로 생각할 수 있습니다. 컨테이너를 생성할 때 컨테이너에 추가 액세스 권한을 부여하지 않는 경우 컨테이너는 이미지에 정의된 리소스에만 액세스할 수 있습니다. OpenShift Container Platform은 여러 호스트의 여러 컨테이너에 동일한 이미지를 배포하고 컨테이너 간에 부하를 분산하여 서비스 패키지 이미지에 중복성과 수평 확장을 제공할 수 있습니다.

Docker CLI를 직접 사용하여 이미지를 빌드할 수 있지만 OpenShift Container Platform에서는 기존 이미지에 코드 또는 구성을 추가하여 새 이미지를 생성하는 데 도움이 되는 빌더 이미지도 제공합니다.

시간이 지남에 따라 애플리케이션이 개발되기 때문에 단일 이미지 이름은 실제로 "동일한" 이미지의 다양한 버전을 참조할 수 있습니다. 서로 다른 각 이미지는 해시 (예: fd44297e2ddb050ec4f…​) 일반적으로 12자로 단축됩니다(예: fd44297e2ddb).

이미지 버전 태그 정책

버전 번호 대신 Docker 서비스를 사용하면 원하는 이미지를 추가로 지정하는 이미지 이름 외에도 태그(예: v1, v2.1,GA 또는 기본 최신)를 적용할 수 있으므로 as centos(가장 최신 태그 사용),centos :centos7 또는 fd44297e2ddb 와 동일한 이미지를 볼 수 있습니다.

이미지에 태그를 지정하는 방법에 따라 업데이트 정책이 지정됩니다. 세부적인 내용이 있을수록 이미지가 업데이트되는 빈도가 줄어듭니다. 다음을 사용하여 선택한 OpenShift Container Platform 이미지 정책을 확인합니다.

컨테이너 이미지 레지스트리는 Docker 형식 컨테이너 이미지를 저장하고 검색하는 서비스입니다. 레지스트리에는 하나 이상의 이미지 리포지토리로 이루어진 컬렉션이 포함되어 있습니다. 각 이미지 리포지토리에는 하나 이상의 태그된 이미지가 포함되어 있습니다. Docker는 자체 레지스트리인 Docker Hub 를 제공하며 개인 또는 타사 레지스트리도 사용할 수 있습니다. Red Hat은 registry.redhat.io의 레지스트리를 구독자에게 제공합니다. OpenShift Container Platform은 사용자 정의 컨테이너 이미지 관리에 사용되는 자체 내부 레지스트리도 제공할 수 있습니다.

컨테이너, 이미지 및 레지스트리 간의 관계는 다음 다이어그램에 표시되어 있습니다.

OpenShift Container Platform은 하나의 호스트에 함께 배포되는 하나 이상의 컨테이너 이자 정의, 배포 및 관리할 수 있는 최소 컴퓨팅 단위인 Pod 의 Kubernetes 개념을 활용합니다.

Pod는 컨테이너에 대한 머신 인스턴스(실제 또는 가상)와 대략적으로 동일합니다. 각 Pod에는 자체 내부 IP 주소가 할당되므로 해당 Pod가 전체 포트 공간을 소유하고 Pod 내의 컨테이너는 로컬 스토리지와 네트워킹을 공유할 수 있습니다.

Pod에는 라이프사이클이 정의되어 있으며 노드에서 실행되도록 할당된 다음 컨테이너가 종료되거나 기타 이유로 제거될 때까지 실행됩니다. Pod는 정책 및 종료 코드에 따라 종료 후 제거되거나 컨테이너 로그에 대한 액세스를 활성화하기 위해 유지될 수 있습니다.

OpenShift Container Platform에서는 대체로 Pod를 변경할 수 없는 것으로 취급합니다. 실행 중에는 Pod 정의를 변경할 수 없습니다. OpenShift Container Platform은 기존 Pod를 종료한 후 수정된 구성이나 기본 이미지 또는 둘 다 사용하여 Pod를 다시 생성하는 방식으로 변경 사항을 구현합니다. Pod를 다시 생성하면 확장 가능한 것으로 취급되고 상태가 유지되지 않습니다. 따라서 일반적으로 포드는 사용자가 직접 관리하는 대신 상위 수준 컨트롤러에서 관리해야 합니다.

다음은 실제로 OpenShift Container Platform 인프라(통합 컨테이너 이미지 레지스트리)의 일부인 장기 실행 서비스를 제공하는 Pod 정의의 예입니다. 이 예제에서는 Pod의 다양한 기능을 보여줍니다. 대부분 다른 주제에서 설명하므로 여기에서는 간단히 언급합니다.

apiVersion: v1
kind: Pod
metadata:
  annotations: { ... }
  labels:                                1
    deployment: docker-registry-1
    deploymentconfig: docker-registry
    docker-registry: default
  generateName: docker-registry-1-       2
spec:
  containers:                            3
  - env:                                 4
    - name: OPENSHIFT_CA_DATA
      value: ...
    - name: OPENSHIFT_CERT_DATA
      value: ...
    - name: OPENSHIFT_INSECURE
      value: "false"
    - name: OPENSHIFT_KEY_DATA
      value: ...
    - name: OPENSHIFT_MASTER
      value: https://master.example.com:8443
    image: openshift/origin-docker-registry:v0.6.2 5
    imagePullPolicy: IfNotPresent
    name: registry
    ports:                              6
    - containerPort: 5000
      protocol: TCP
    resources: {}
    securityContext: { ... }            7
    volumeMounts:                       8
    - mountPath: /registry
      name: registry-storage
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-br6yz
      readOnly: true
  dnsPolicy: ClusterFirst
  imagePullSecrets:
  - name: default-dockercfg-at06w
  restartPolicy: Always                 9
  serviceAccount: default               10
  volumes:                              11
  - emptyDir: {}
    name: registry-storage
  - name: default-token-br6yz
    secret:
      secretName: default-token-br6yz

init 컨테이너 는 Pod 앱 컨테이너를 시작하기 전에 시작되는 Pod의 컨테이너입니다. Init 컨테이너는 나머지 컨테이너가 시작되기 전에 볼륨을 공유하고, 네트워크 작업을 수행하고, 계산을 수행할 수 있습니다. Init 컨테이너는 일부 사전 조건이 충족될 때까지 애플리케이션 컨테이너의 시작을 차단하거나 지연할 수도 있습니다.

Pod가 시작되면 네트워크와 볼륨을 초기화한 후 init 컨테이너가 순서대로 시작됩니다. 각 init 컨테이너는 다음이 호출되기 전에 성공적으로 종료해야 합니다. init 컨테이너가 시작되지 않거나(런타임) 실패로 종료되면 Pod 재시작 정책에 따라 다시 시작됩니다.

Pod는 모든 init 컨테이너가 성공할 때까지 준비할 수 없습니다.

일부 init 컨테이너 사용 예는 Kubernetes 설명서를 참조하십시오.

다음 예제에서는 두 개의 init 컨테이너가 있는 간단한 포드를 간략하게 설명합니다. 첫 번째 init 컨테이너는 myservice 를 대기하고 두 번째 컨테이너는 mydb 를 기다립니다. 두 컨테이너가 모두 성공하면 Pod가 시작됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice 1
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb 2
    image: busybox
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

각 init 컨테이너에는 readinessProbe 를 제외한 모든 app 컨테이너의 필드가 있습니다. Pod가 계속 시작되려면 Init 컨테이너가 종료되어야 하며 완료 이외의 준비는 정의할 수 없습니다.

Init 컨테이너는 컨테이너에 activeDeadlineSeconds 및 livenessProbe 를 포함하여 init 컨테이너가 영구적으로 실패하지 않도록 할 수 있습니다. 활성 데드라인에는 init 컨테이너가 포함됩니다.

Kubernetes 서비스는 내부 로드 밸런서 역할을 합니다. 수신 연결을 프록시하기 위해 복제된 포드 집합을 식별합니다. 서비스에 의존하는 모든 항목이 일관된 주소에서 참조할 수 있도록 백업 포드를 서비스에 임의로 추가하거나 제거할 수 있습니다. 기본 서비스 clusterIP 주소는 OpenShift Container Platform 내부 네트워크에서 제공되며 포드가 서로 액세스할 수 있도록 허용하는 데 사용됩니다.

서비스에 대한 외부 액세스를 허용하려면 클러스터 외부에 있는 추가 externalIP 및 ingressIP 주소를 서비스에 할당할 수 있습니다. 이러한 externalIP 주소는 서비스에 대한 고가용성 액세스를 제공하는 가상 IP 주소일 수도 있습니다.

서비스에 액세스할 때 적절한 지원 포드로 프록시하는 IP 주소 및 포트 쌍이 할당됩니다. 서비스는 레이블 선택기를 사용하여 특정 포트에서 특정 네트워크 서비스를 제공하는 실행 중인 모든 컨테이너를 찾습니다.

포드와 마찬가지로 서비스는 REST 개체입니다. 다음 예는 위에서 정의한 Pod에 대한 서비스 정의를 보여줍니다.

apiVersion: v1
kind: Service
metadata:
  name: docker-registry      1
spec:
  selector:                  2
    docker-registry: default
  clusterIP: 172.30.136.123   3
  ports:
  - nodePort: 0
    port: 5000               4
    protocol: TCP
    targetPort: 5000         5

Kubernetes 설명서 에는 서비스에 대한 자세한 정보가 있습니다.

networkConfig:
  externalIPNetworkCIDRs:
  - 192.0.1.0.0/24

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "MyApp"
        },
        "ports": [
            {
                "name": "http",
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376
            }
        ],
        "externalIPs" : [
            "192.0.1.1"         1
        ]
    }
}

networkConfig:
  ingressIPNetworkCIDR: 172.29.0.0/16

kubernetesMasterConfig:
  servicesNodePortRange: ""

$ oc get pods -o wide

NAME               READY  STATUS    RESTARTS   AGE    IP            NODE
frontend-1-287hw   1/1    Running   0          7m     172.17.0.3    node_1
frontend-1-68km5   1/1    Running   0          7m     172.17.0.6    node_1

apiVersion: v1
kind: Service
metadata:
  labels:
    app: ruby-helloworld-sample
    template: application-template-stibuild
  name: frontend-headless 1
spec:
  clusterIP: None 2
  ports:
  - name: web
    port: 5432
    protocol: TCP
    targetPort: 8080
  selector:
    name: frontend 3
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

$ oc get svc

NAME                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
frontend            ClusterIP   172.30.232.77    <none>        5432/TCP   12m
frontend-headless   ClusterIP   None             <none>        5432/TCP   10m

$ dig frontend.test A +search +short

172.30.232.77

$ dig frontend-headless.test A +search +short

172.17.0.3
172.17.0.6

레이블은 API 오브젝트를 구성, 그룹화 또는 선택하는 데 사용됩니다. 예를 들어 Pod 는 레이블이 있는 "태그"에 해당된 다음 서비스에서 라벨 선택기를 사용하여 프록시할 포드를 식별합니다. 이렇게 하면 잠재적으로 다른 컨테이너가 있는 Pod를 관련 엔터티로 처리해도 서비스가 포드 그룹을 참조할 수 있습니다.

대부분의 오브젝트는 메타데이터에 레이블을 포함할 수 있습니다. 따라서 레이블을 사용하여 임의로 관련된 오브젝트를 그룹화할 수 있습니다. 예를 들어 특정 애플리케이션의 모든 포드,서비스,복제 컨트롤러 및 배포 구성을 그룹화할 수 있습니다.

레이블은 다음 예와 같이 간단한 키/값 쌍입니다.

labels:
  key1: value1
  key2: value2

고려 사항:

role=webserver 레이블이 있는 포드를 사용하도록 정의된 서비스 또는 복제 컨트롤러는 이러한 포드를 모두 동일한 그룹의 일부로 취급합니다.

Kubernetes 설명서 에는 레이블에 대한 자세한 정보가 있습니다.

서비스를 지원하는 서버를 엔드포인트라고 하며, 서비스와 동일한 이름으로 Endpoints 유형의 오브젝트에 의해 지정됩니다. Pod에서 서비스를 지원하는 경우 일반적으로 해당 Pod는 서비스 사양의 라벨 선택기에 의해 지정되며 OpenShift Container Platform은 해당 Pod를 가리키는 Endpoints 오브젝트를 자동으로 생성합니다.

경우에 따라 서비스를 생성하지만 OpenShift Container Platform 클러스터의 Pod가 아닌 외부 호스트에서 지원하도록 할 수 있습니다. 이 경우 서비스에서 selector 필드를 종료하고 끝점 오브젝트를 수동으로 생성할 수 있습니다.

OpenShift Container Platform에서는 대부분의 사용자가 Pod 및 서비스 IP용으로 예약된 네트워크 블록에서 IP 주소를 가리키는 엔드포인트 오브젝트를 수동으로 생성하지 않습니다. 엔드포인트/제한에서 리소스를 생성할 수 있는 권한이 있는 클러스터 관리자 또는 기타 사용자만 이러한 엔드포인트 오브젝트를 생성할 수 있습니다.

OpenShift Container Platform과의 상호 작용은 사용자와 연결되어 있습니다. OpenShift Container Platform 사용자 오브젝트는 시스템에서 역할을 추가하여 권한을 부여받을 수 있는 행위자를 나타냅니다.

다음과 같이 여러 유형의 사용자가 존재할 수 있습니다.

모든 사용자가 OpenShift Container Platform에 액세스하려면 어떠한 방식으로든 인증 해야 합니다. 인증이 없거나 인증이 유효하지 않은 API 요청은 anonymous 시스템 사용자가 요청한 것으로 인증됩니다. 인증되고 나면 정책에 따라 사용자가 수행할 수 있는 작업이 결정됩니다.

Kubernetes 네임스페이스는 클러스터의 리소스 범위를 지정하는 메커니즘을 제공합니다. OpenShift Container Platform에서 프로젝트는 추가 주석이 있는 Kubernetes 네임스페이스입니다.

네임스페이스는 다음에 대한 고유 범위를 제공합니다.

시스템에 있는 대부분의 오브젝트는 네임스페이스에 따라 범위가 지정되지만, 노드 및 사용자를 비롯한 일부는 여기에 해당하지 않으며 네임스페이스가 없습니다.

쿠버네티스 설명서에 네임스페이스에 대한 자세한 정보가 있습니다.

프로젝트는 추가 주석이 있는 Kubernetes 네임스페이스이며 일반 사용자의 리소스에 대한 액세스를 관리하는 핵심 수단입니다. 사용자 커뮤니티는 프로젝트를 통해 다른 커뮤니티와 별도로 콘텐츠를 구성하고 관리할 수 있습니다. 사용자는 관리자로부터 프로젝트에 대한 액세스 권한을 부여받아야 합니다. 프로젝트를 생성하도록 허용된 경우 자신의 프로젝트에 액세스할 수 있는 권한이 자동으로 제공됩니다.

프로젝트에는 별도의 이름, displayName 및 설명이 있을 수 있습니다.

각 프로젝트의 범위는 다음과 같습니다.

클러스터 관리자는 프로젝트를 생성하고 프로젝트에 대한 관리 권한을 사용자 커뮤니티의 모든 멤버에게 위임할 수 있습니다. 클러스터 관리자는 개발자가 자신의 프로젝트를 만들 수 있도록 허용할 수도 있습니다.

개발자와 관리자는 CLI 또는 웹 콘솔을 사용하여 프로젝트와 상호 작용할 수 있습니다.

빌드는 입력 매개 변수를 결과 오브젝트로 변환하는 프로세스입니다. 대부분의 경우 프로세스는 입력 매개변수 또는 소스 코드를 실행 가능한 이미지로 변환하는 데 사용됩니다. BuildConfig 오브젝트는 전체 빌드 프로세스에 대한 정의입니다.

OpenShift Container Platform은 빌드 이미지에서 Docker 형식 컨테이너를 생성하고 컨테이너 이미지 레지스트리로 내보내 Kubernetes를 활용합니다.

빌드 오브젝트는 공통 특성을 공유합니다. 빌드에 대한 입력, 빌드 프로세스를 완료하고, 빌드 프로세스를 로깅하고, 빌드에 성공한 빌드의 리소스를 게시하고, 빌드의 최종 상태를 게시해야 합니다. 빌드에서는 CPU 사용량, 메모리 사용량, 빌드 또는 Pod 실행 시간과 같은 리소스 제한 사항을 활용합니다.

OpenShift Container Platform 빌드 시스템은 빌드 API에 지정된 선택 가능한 유형을 기반으로 하는 빌드 전략에 대한 확장 가능한 지원을 제공합니다. 다음은 세 가지 주요 빌드 전략입니다.

기본적으로 Docker 빌드 및 S2I 빌드가 지원됩니다.

빌드의 결과 오브젝트는 빌드를 생성하는 데 사용된 빌더에 따라 다릅니다. Docker 및 S2I 빌드의 경우 결과 오브젝트는 실행 가능한 이미지입니다. 사용자 정의 빌드의 경우 결과 오브젝트는 빌더 이미지 작성자가 지정한 모든 항목입니다.

또한 Pipeline 빌드 전략을 사용하여 정교한 워크플로를 구현할 수 있습니다.

빌드 명령 목록은 개발자 가이드를 참조하십시오.

OpenShift Container Platform이 빌드를 위해 Docker를 활용하는 방법에 대한 자세한 내용은 업스트림 문서를 참조하십시오.

이미지 스트림 및 관련 태그는 OpenShift Container Platform 내에서 컨테이너 이미지를 참조하기 위한 추상화를 제공합니다. 이미지 스트림 및 해당 태그를 사용하면 사용 가능한 이미지를 볼 수 있으며 리포지터리의 이미지가 변경되어도 필요한 특정 이미지를 사용하도록 할 수 있습니다.

이미지 스트림에는 실제 이미지 데이터가 포함되어 있지 않지만 이미지 리포지터리와 유사하게 관련 이미지에 대한 단일 가상 뷰가 있습니다.

새 이미지가 추가되는 경우 이미지 스트림에서 알림을 보고 빌드 또는 배포를 각각 수행하여 대응하도록 빌드 및 배포를 구성할 수 있습니다.

예를 들어 배포에서 특정 이미지를 사용하고 있는데 해당 이미지의 새 버전이 생성되는 경우 배포가 자동으로 수행되어 새 버전의 이미지를 가져올 수 있습니다.

그러나 배포 또는 빌드에서 사용하는 이미지 스트림 태그가 업데이트되지 않으면 컨테이너 이미지 레지스트리의 컨테이너 이미지가 업데이트되어도 빌드 또는 배포에서 이전(알려진 정상) 이미지를 계속 사용합니다.

소스 이미지를 저장할 수 있는 위치는 다음과 같습니다.

이미지 스트림 태그(예: 빌드 또는 배포 구성)를 참조하는 오브젝트를 정의하는 경우 Docker 리포지토리가 아닌 이미지 스트림 태그를 가리킵니다. 애플리케이션을 빌드하거나 배포할 때 OpenShift Container Platform은 이미지 스트림 태그를 사용하여 Docker 리포지토리를 쿼리하여 관련 이미지 ID를 찾고 바로 그 이미지를 사용합니다.

이미지 스트림 메타데이터는 다른 클러스터 정보와 함께 etcd 인스턴스에 저장됩니다.

다음 이미지 스트림에는 두 개의 태그가 포함되어 있습니다. 34 Python v3.4 이미지와 35 를 가리켜 Python v3.5 이미지를 가리킵니다.

$ oc describe is python

Name:			python
Namespace:		imagestream
Created:		25 hours ago
Labels:			app=python
Annotations:		openshift.io/generated-by=OpenShiftWebConsole
			openshift.io/image.dockerRepositoryCheck=2017-10-03T19:48:00Z
Docker Pull Spec:	docker-registry.default.svc:5000/imagestream/python
Image Lookup:		local=false
Unique Images:		2
Tags:			2

34
  tagged from centos/python-34-centos7

  * centos/python-34-centos7@sha256:28178e2352d31f240de1af1370be855db33ae9782de737bb005247d8791a54d0
      14 seconds ago

35
  tagged from centos/python-35-centos7

  * centos/python-35-centos7@sha256:2efb79ca3ac9c9145a63675fb0c09220ab3b8d4005d35e0644417ee552548b10
      7 seconds ago

이미지 스트림을 사용하면 다음과 같은 여러 중요한 이점이 있습니다.

조정된 이미지 스트림 세트는 OpenShift Image Streams 및 Templates 라이브러리 를 참조하십시오.

이미지 스트림을 사용할 때는 이미지 스트림 태그가 가리키는 사항과 태그 및 이미지를 변경하는 방법을 이해해야 합니다. 예를 들면 다음과 같습니다.

docker.io/openshift/jenkins-2-centos7:3.6.0

docker.io/openshift/jenkins-2-centos7@sha256:ab312bda324

apiVersion: v1
kind: ImageStream
metadata:
  annotations:
    openshift.io/generated-by: OpenShiftNewApp
  creationTimestamp: 2017-09-29T13:33:49Z
  generation: 1
  labels:
    app: ruby-sample-build
    template: application-template-stibuild
  name: origin-ruby-sample 1
  namespace: test
  resourceVersion: "633"
  selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
  uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
  dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample 2
  tags:
  - items:
    - created: 2017-09-02T10:15:09Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d 3
      generation: 2
      image: sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5 4
    - created: 2017-09-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
      generation: 1
      image: sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
    tag: latest 5

<image-stream-name>@<image-id>

origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d

  tags:
  - items:
    - created: 2017-09-02T10:15:09Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
      generation: 2
      image: sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
    - created: 2017-09-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:909de62d1f609a717ec433cc25ca5cf00941545c83a01fb31527771e1fab3fc5
      generation: 1
      image: sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d
    tag: latest

<image stream name>:<tag>

origin-ruby-sample:latest

triggers:
  - type: "ImageChange"
    imageChangeParams:
      automatic: true 1
      from:
        kind: "ImageStreamTag"
        name: "origin-ruby-sample:latest"
        namespace: "myproject"
      containerNames:
        - "helloworld"

apiVersion: v1
kind: ImageStreamMapping
metadata:
  creationTimestamp: null
  name: origin-ruby-sample
  namespace: test
tag: latest
image:
  dockerImageLayers:
  - name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
    size: 0
  - name: sha256:ee1dd2cb6df21971f4af6de0f1d7782b81fb63156801cfde2bb47b4247c23c29
    size: 196634330
  - name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
    size: 0
  - name: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
    size: 0
  - name: sha256:ca062656bff07f18bff46be00f40cfbb069687ec124ac0aa038fd676cfaea092
    size: 177723024
  - name: sha256:63d529c59c92843c395befd065de516ee9ed4995549f8218eac6ff088bfa6b6e
    size: 55679776
  - name: sha256:92114219a04977b5563d7dff71ec4caa3a37a15b266ce42ee8f43dba9798c966
    size: 11939149
  dockerImageMetadata:
    Architecture: amd64
    Config:
      Cmd:
      - /usr/libexec/s2i/run
      Entrypoint:
      - container-entrypoint
      Env:
      - RACK_ENV=production
      - OPENSHIFT_BUILD_NAMESPACE=test
      - OPENSHIFT_BUILD_SOURCE=https://github.com/openshift/ruby-hello-world.git
      - EXAMPLE=sample-app
      - OPENSHIFT_BUILD_NAME=ruby-sample-build-1
      - PATH=/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      - STI_SCRIPTS_URL=image:///usr/libexec/s2i
      - STI_SCRIPTS_PATH=/usr/libexec/s2i
      - HOME=/opt/app-root/src
      - BASH_ENV=/opt/app-root/etc/scl_enable
      - ENV=/opt/app-root/etc/scl_enable
      - PROMPT_COMMAND=. /opt/app-root/etc/scl_enable
      - RUBY_VERSION=2.2
      ExposedPorts:
        8080/tcp: {}
      Labels:
        build-date: 2015-12-23
        io.k8s.description: Platform for building and running Ruby 2.2 applications
        io.k8s.display-name: 172.30.56.218:5000/test/origin-ruby-sample:latest
        io.openshift.build.commit.author: Ben Parees <bparees@users.noreply.github.com>
        io.openshift.build.commit.date: Wed Jan 20 10:14:27 2016 -0500
        io.openshift.build.commit.id: 00cadc392d39d5ef9117cbc8a31db0889eedd442
        io.openshift.build.commit.message: 'Merge pull request #51 from php-coder/fix_url_and_sti'
        io.openshift.build.commit.ref: master
        io.openshift.build.image: centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
        io.openshift.build.source-location: https://github.com/openshift/ruby-hello-world.git
        io.openshift.builder-base-version: 8d95148
        io.openshift.builder-version: 8847438ba06307f86ac877465eadc835201241df
        io.openshift.s2i.scripts-url: image:///usr/libexec/s2i
        io.openshift.tags: builder,ruby,ruby22
        io.s2i.scripts-url: image:///usr/libexec/s2i
        license: GPLv2
        name: CentOS Base Image
        vendor: CentOS
      User: "1001"
      WorkingDir: /opt/app-root/src
    Container: 86e9a4a3c760271671ab913616c51c9f3cea846ca524bf07c04a6f6c9e103a76
    ContainerConfig:
      AttachStdout: true
      Cmd:
      - /bin/sh
      - -c
      - tar -C /tmp -xf - && /usr/libexec/s2i/assemble
      Entrypoint:
      - container-entrypoint
      Env:
      - RACK_ENV=production
      - OPENSHIFT_BUILD_NAME=ruby-sample-build-1
      - OPENSHIFT_BUILD_NAMESPACE=test
      - OPENSHIFT_BUILD_SOURCE=https://github.com/openshift/ruby-hello-world.git
      - EXAMPLE=sample-app
      - PATH=/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      - STI_SCRIPTS_URL=image:///usr/libexec/s2i
      - STI_SCRIPTS_PATH=/usr/libexec/s2i
      - HOME=/opt/app-root/src
      - BASH_ENV=/opt/app-root/etc/scl_enable
      - ENV=/opt/app-root/etc/scl_enable
      - PROMPT_COMMAND=. /opt/app-root/etc/scl_enable
      - RUBY_VERSION=2.2
      ExposedPorts:
        8080/tcp: {}
      Hostname: ruby-sample-build-1-build
      Image: centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
      OpenStdin: true
      StdinOnce: true
      User: "1001"
      WorkingDir: /opt/app-root/src
    Created: 2016-01-29T13:40:00Z
    DockerVersion: 1.8.2.fc21
    Id: 9d7fd5e2d15495802028c569d544329f4286dcd1c9c085ff5699218dbaa69b43
    Parent: 57b08d979c86f4500dc8cad639c9518744c8dd39447c055a3517dc9c18d6fccd
    Size: 441976279
    apiVersion: "1.0"
    kind: DockerImage
  dockerImageMetadataVersion: "1.0"
  dockerImageReference: 172.30.56.218:5000/test/origin-ruby-sample@sha256:47463d94eb5c049b2d23b03a9530bf944f8f967a0fe79147dd6b9135bf7dd13d

$ oc describe is/<image-name>

$ oc describe is/python

Name:			python
Namespace:		default
Created:		About a minute ago
Labels:			<none>
Annotations:		openshift.io/image.dockerRepositoryCheck=2017-10-02T17:05:11Z
Docker Pull Spec:	docker-registry.default.svc:5000/default/python
Image Lookup:		local=false
Unique Images:		1
Tags:			1

3.5
  tagged from centos/python-35-centos7

  * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
      About a minute ago

$ oc describe istag/<image-stream>:<tag-name>

$ oc describe istag/python:latest

Image Name:	sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
Docker Image:	centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
Name:		sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
Created:	2 minutes ago
Image Size:	251.2 MB (first layer 2.898 MB, last binary layer 72.26 MB)
Image Created:	2 weeks ago
Author:		<none>
Arch:		amd64
Entrypoint:	container-entrypoint
Command:	/bin/sh -c $STI_SCRIPTS_PATH/usage
Working Dir:	/opt/app-root/src
User:		1001
Exposes Ports:	8080/tcp
Docker Labels:	build-date=20170801

oc tag <image-name:tag> <image-name:tag>

$ oc tag python:3.5 python:latest

Tag python:latest set to python@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25.

$ oc describe is/python

Name:			python
Namespace:		default
Created:		5 minutes ago
Labels:			<none>
Annotations:		openshift.io/image.dockerRepositoryCheck=2017-10-02T17:05:11Z
Docker Pull Spec:	docker-registry.default.svc:5000/default/python
Image Lookup:		local=false
Unique Images:		1
Tags:			2

latest
  tagged from python@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25

  * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
      About a minute ago

3.5
  tagged from centos/python-35-centos7

  * centos/python-35-centos7@sha256:49c18358df82f4577386404991c51a9559f243e0b1bdc366df25
      5 minutes ago

$ oc tag <repositiory/image> <image-name:tag>

$ oc tag docker.io/python:3.6.0 python:3.6

Tag python:3.6 set to docker.io/python:3.6.0.

$ oc tag <image-name:tag> <image-name:latest>

$ oc tag python:3.6 python:latest

Tag python:latest set to python@sha256:438208801c4806548460b27bd1fbcb7bb188273d13871ab43f.

$ oc tag -d <image-name:tag>

$ oc tag -d python:3.5

Deleted tag default/python:3.5.

$ oc tag <repositiory/image> <image-name:tag> --scheduled

$ oc tag docker.io/python:3.6.0 python:3.6 --scheduled

Tag python:3.6 set to import docker.io/python:3.6.0 periodically.

$ oc tag <repositiory/image> <image-name:tag>

복제 컨트롤러를 사용하면 항상 지정된 수의 포드 복제본이 실행됩니다. Pod가 종료되거나 삭제되면 복제 컨트롤러가 작동하여 정의된 수까지 추가로 인스턴스화합니다. 마찬가지로 필요한 것보다 많은 Pod가 실행되고 있는 경우에는 정의된 수에 맞게 필요한 개수의 Pod를 삭제합니다.

복제 컨트롤러 구성은 다음과 같이 구성됩니다.

선택기는 복제 컨트롤러에서 관리하는 Pod에 할당한 라벨 세트입니다. 이러한 레이블은 복제 컨트롤러가 인스턴스화하는 포드 정의에 포함됩니다. 복제 컨트롤러에서는 필요에 따라 조정할 수 있도록 선택기를 사용하여 이미 실행 중인 Pod의 인스턴스 수를 결정합니다.

복제 컨트롤러에서 로드나 트래픽을 추적하지 않으므로 로드 또는 트래픽을 기반으로 자동 스케일링하지 않습니다. 대신 외부 자동 확장기에서 복제본 수를 조정해야 합니다.

복제 컨트롤러는 ReplicationController 라는 핵심 Kubernetes 오브젝트입니다.

다음은 ReplicationController 정의의 예입니다.

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend-1
spec:
  replicas: 1  1
  selector:    2
    name: frontend
  template:    3
    metadata:
      labels:  4
        name: frontend 5
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always

복제 컨트롤러와 유사하게 복제본 세트는 지정된 수의 포드 복제본이 언제든지 실행되도록 합니다. 복제본 세트와 복제 컨트롤러의 차이점은 복제본 세트는 세트 기반 선택기 요구 사항을 지원하는 반면 복제 컨트롤러는 일치 기반 선택기 요구 사항만 지원한다는 점입니다.

복제본 세트는 ReplicaSet 이라는 핵심 Kubernetes 오브젝트입니다.

다음은 ReplicaSet 정의의 예입니다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend-1
  labels:
    tier: frontend
spec:
  replicas: 3
  selector: 1
    matchLabels: 2
      tier: frontend
    matchExpressions: 3
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - image: openshift/hello-openshift
        name: helloworld
        ports:
        - containerPort: 8080
          protocol: TCP
      restartPolicy: Always

작업은 복제 컨트롤러와 비슷하며, 이는 지정된 이유로 포드를 생성하는 것입니다. 차이점은 복제 컨트롤러는 지속적으로 실행 중인 포드를 위해 설계된 반면 작업은 일회성 포드를 위한 것입니다. 작업은 완료를 추적하며 지정된 수의 완료에 도달하면 작업 자체가 완료됩니다.

다음 예제에서는 ✓~ 2000개의 위치를 계산하여 출력한 다음 다음과 같이 완료합니다.

apiVersion: extensions/v1
kind: Job
metadata:
  name: pi
spec:
  selector:
    matchLabels:
      app: pi
  template:
    metadata:
      name: pi
      labels:
        app: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

작업 사용 방법에 대한 자세한 내용은 Jobs (작업) 주제를 참조하십시오.

복제 컨트롤러를 기반으로 OpenShift Container Platform은 배포 개념을 사용하여 소프트웨어 개발 및 배포 라이프사이클에 대한 확장된 지원을 추가합니다. 가장 간단한 경우 배포는 새 복제 컨트롤러만 생성하고 포드를 시작할 수 있도록 합니다. 그러나 OpenShift Container Platform 배포에서는 이미지의 기존 배포에서 새 배포로 전환하고 복제 컨트롤러를 생성하기 전이나 후에 실행할 후크도 정의할 수 있습니다.

OpenShift Container Platform DeploymentConfig 오브젝트는 배포에 대한 다음 세부 정보를 정의합니다.

배포가 수동 또는 자동으로 트리거될 때마다 배포자 Pod에서 배포를 관리합니다(이전 복제 컨트롤러 축소, 새 복제 컨트롤러 확장, 후크 실행 포함). 배포 Pod는 배포 로그를 유지하기 위해 배포 완료 후 무기한으로 유지됩니다. 배포가 다른 배포로 대체되면 필요한 경우 쉽게 롤백할 수 있도록 이전 복제 컨트롤러가 유지됩니다.

배포를 만들고 상호 작용하는 방법에 대한 자세한 지침은 배포를 참조하십시오.

다음은 일부 omissions 및 callouts가 포함된 예제 DeploymentConfig 정의입니다.

apiVersion: v1
kind: DeploymentConfig
metadata:
  name: frontend
spec:
  replicas: 5
  selector:
    name: frontend
  template: { ... }
  triggers:
  - type: ConfigChange 1
  - imageChangeParams:
      automatic: true
      containerNames:
      - helloworld
      from:
        kind: ImageStreamTag
        name: hello-openshift:latest
    type: ImageChange  2
  strategy:
    type: Rolling      3

템플릿은 OpenShift Container Platform에서 생성할 오브젝트 목록을 생성하기 위해 매개 변수화 및 처리할 수 있는 오브젝트 세트를 설명합니다. 생성할 오브젝트에는 서비스, 빌드 구성 및 배포 구성과 같이 프로젝트 내에서 생성할 권한이 있는 모든 항목이 포함될 수 있습니다. 템플릿은 템플릿에 정의된 모든 오브젝트에 적용할 레이블 집합도 정의할 수 있습니다.

템플릿 생성 및 사용에 대한 자세한 내용은 템플릿 가이드를 참조하십시오.

그러면 인증 계층에서 OpenShift Container Platform API에 대한 요청과 관련된 사용자를 확인합니다. 그런 다음 권한 부여 계층에서는 요청하는 사용자에 대한 정보를 사용하여 요청을 허용해야 하는지 여부를 결정합니다.

관리자는 마스터 구성 파일을 사용하여 인증을 구성할 수 있습니다.

OpenShift Container Platform에서 사용자는 OpenShift Container Platform API에 요청할 수 있는 엔티티입니다. 일반적으로 OpenShift Container Platform과 상호 작용하는 개발자 또는 관리자 계정을 의미합니다.

사용자는 하나 이상의 그룹에 할당될 수 있으며, 각 그룹은 특정 사용자 집합을 나타냅니다. 그룹은 사용자에게 개별적으로 부여하는 대신 권한 부여 정책을 관리하여 여러 사용자에게 한 번에 권한을 부여할 때 유용합니다(예: 프로젝트 내 오브젝트에 대한 액세스 허용).

명시적으로 정의된 그룹 외에도 OpenShift에서 자동으로 프로비저닝하는 시스템 그룹 또는 가상 그룹이 있습니다. 클러스터 바인딩을 볼 때 볼 수 있습니다.

가상 그룹의 기본 집합에서는 특히 다음 사항에 유의하십시오.

OpenShift Container Platform API에 대한 요청은 다음과 같은 방법으로 인증됩니다.

유효하지 않은 액세스 토큰 또는 유효하지 않은 인증서가 있는 요청은 401 오류와 함께 인증 계층에서 거부됩니다.

액세스 토큰이나 인증서가 없는 경우 인증 계층은 system:anonymous 가상 사용자 및 system:unauthenticated 가상 그룹을 요청에 할당합니다. 그러면 권한 부여 계층에서 익명 사용자가 할 수 있는 요청(있는 경우)을 결정합니다.

$ oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username>

$ oc new-project <project> --as=<user> \
--as-group=system:authenticated --as-group=system:authenticated:oauth

OpenShift Container Platform 마스터에는 내장 OAuth 서버가 포함되어 있습니다. 사용자는 API 인증을 위해 OAuth 액세스 토큰을 가져옵니다.

사용자가 새 OAuth 토큰을 요청하면 OAuth 서버는 구성된 ID 공급자를 사용하여 요청한 사용자의 ID를 확인합니다.

그런 다음 해당 ID와 매핑되는 사용자를 결정하고 그 사용자를 위한 액세스 토큰을 만들어 제공합니다.

$ oc create -f <(echo '
kind: OAuthClient
apiVersion: oauth.openshift.io/v1
metadata:
 name: demo 1
secret: "..." 2
redirectURIs:
 - "http://www.example.com/" 3
grantMethod: prompt 4
')

serviceaccounts.openshift.io/oauth-redirecturi.<name>

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "https://example.com"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": "Route",
    "name": "jenkins"
  }
}

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": ..., 1
    "name": ..., 2
    "group": ... 3
  }
}

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second":  "//:8000"
"serviceaccounts.openshift.io/oauth-redirectreference.second": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

$ oc get events | grep ServiceAccount

1m         1m          1         proxy                    ServiceAccount                                  Warning   NoSAOAuthRedirectURIs   service-account-oauth-client-getter   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

$ oc describe sa/proxy | grep -A5 Events

Events:
  FirstSeen     LastSeen        Count   From                                    SubObjectPath   Type            Reason                  Message
  ---------     --------        -----   ----                                    -------------   --------        ------                  -------
  3m            3m              1       service-account-oauth-client-getter                     Warning         NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

Reason                  Message
NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

Reason                  Message
NoSAOAuthRedirectURIs   [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

Reason                  Message
NoSAOAuthRedirectURIs   [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

Reason                  Message
NoSAOAuthTokens         system:serviceaccount:myproject:proxy has no tokens

{
  "issuer": "https://<master>", 1
  "authorization_endpoint": "https://<master>/oauth/authorize", 2
  "token_endpoint": "https://<master>/oauth/token", 3
  "scopes_supported": [ 4
    "user:full",
    "user:info",
    "user:check-access",
    "user:list-scoped-projects",
    "user:list-projects"
  ],
  "response_types_supported": [ 5
    "code",
    "token"
  ],
  "grant_types_supported": [ 6
    "authorization_code",
    "implicit"
  ],
  "code_challenge_methods_supported": [ 7
    "plain",
    "S256"
  ]
}

$ curl -H "X-Remote-User: <username>" \
     --cacert /etc/origin/master/ca.crt \
     --cert /etc/origin/master/admin.crt \
     --key /etc/origin/master/admin.key \
     -I https://<master-address>/oauth/authorize?response_type=token\&client_id=openshift-challenging-client | grep -oP "access_token=\K[^&]*"

$ curl -u <username>:<password>
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -skv / 1
/ -H "X-CSRF-Token: xxx" 2

*   Trying 10.64.33.43...
* Connected to 10.64.33.43 (10.64.33.43) port 8443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*        server certificate verification SKIPPED
*        server certificate status verification SKIPPED
*        common name: 10.64.33.43 (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: CN=10.64.33.43
*        start date: Thu, 09 Aug 2018 04:00:39 GMT
*        expire date: Sat, 08 Aug 2020 04:00:40 GMT
*        issuer: CN=openshift-signer@1531109367
*        compression: NULL
* ALPN, server accepted to use http/1.1
* Server auth using Basic with user 'developer'
> GET /oauth/authorize?client_id=openshift-challenging-client&response_type=token HTTP/1.1
> Host: 10.64.33.43:8443
> Authorization: Basic ZGV2ZWxvcGVyOmRzc2Zkcw==
> User-Agent: curl/7.47.0
> Accept: */*
> X-CSRF-Token: xxx
>
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location:
https://10.64.33.43:8443/oauth/token/implicit#access_token=gzTwOq_mVJ7ovHliHBTgRQEEXa1aCZD9lnj7lSw3ekQ&expires_in=86400&scope=user%3Afull&token_type=Bearer 1
< Pragma: no-cache
< Set-Cookie: ssn=MTUzNTk0OTc1MnxIckVfNW5vNFlLSlF5MF9GWEF6Zm55Vl95bi1ZNE41S1NCbFJMYnN1TWVwR1hwZmlLMzFQRklzVXRkc0RnUGEzdnBEa0NZZndXV2ZUVzN1dmFPM2dHSUlzUmVXakQ3Q09rVXpxNlRoVmVkQU5DYmdLTE9SUWlyNkJJTm1mSDQ0N2pCV09La3gzMkMzckwxc1V1QXpybFlXT2ZYSmI2R2FTVEZsdDBzRjJ8vk6zrQPjQUmoJCqb8Dt5j5s0b4wZlITgKlho9wlKAZI=; Path=/; HttpOnly; Secure
< Date: Mon, 03 Sep 2018 04:42:32 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host 10.64.33.43 left intact

$ curl -u <username>:<password> /
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' / 1
-skv -H "X-CSRF-Token: xxx" --stderr - |  grep -oP "access_token=\K[^&]*" 2

hvqxe5aMlAzvbqfM2WWw3D6tR0R2jCQGKx0viZBxwmc

RBAC(역할 기반 액세스 제어) 오브젝트는 사용자가 프로젝트 내에서 지정된 작업을 수행할 수 있는지 여부를 결정합니다.

이를 통해 플랫폼 관리자는 클러스터 역할 및 바인딩 을 사용하여 OpenShift Container Platform 플랫폼 자체와 모든 프로젝트에 대해 다양한 액세스 수준을 보유한 사용자를 제어할 수 있습니다.

이를 통해 개발자는 로컬 역할 및 바인딩 을 사용하여 프로젝트에 액세스할 수 있는 사용자를 제어할 수 있습니다. 권한 부여는 인증과 별도의 단계이며 , 이는 조치를 수행할 사용자의 ID를 결정하는 데 더 중요합니다.

권한 부여는 다음을 사용하여 관리합니다.

클러스터 관리자는 CLI를 사용하여 규칙, 역할 및 바인딩을 시각화할 수 있습니다.

예를 들어 admin 및 basic-user 기본 클러스터 역할에 대한 규칙 세트를 보여주는 다음 발췌 사항을 고려하십시오.

$ oc describe clusterrole.rbac admin basic-user

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]

로컬 역할 바인딩 보기의 다음 발췌 내용은 다양한 사용자 및 그룹에 바인딩된 위의 역할을 보여줍니다.

$ oc describe rolebinding.rbac admin basic-user -n alice-project

Name:		admin
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	admin
Subjects:
  Kind	Name		Namespace
  ----	----		---------
  User	system:admin
  User	alice


Name:		basic-user
Labels:		<none>
Annotations:	<none>
Role:
  Kind:	ClusterRole
  Name:	basic-user
Subjects:
  Kind	Name	Namespace
  ----	----	---------
  User	joe
  Group	devel

아래에는 클러스터 역할, 로컬 역할, 클러스터 역할 바인딩, 로컬 역할 바인딩, 사용자, 그룹, 서비스 계정 간의 관계가 설명되어 있습니다.

OpenShift Container Platform에서 권한 부여를 평가할 때 몇 가지 요소가 결합되어 결정됩니다.

OpenShift Container Platform은 다음 단계를 사용하여 권한 부여를 평가합니다.

권한 부여를 제어하는 두 가지 수준의 RBAC 역할 및 바인딩이 있습니다.

이 2단계 계층 구조에서는 클러스터 역할을 통해 여러 프로젝트에서 재사용할 수 있는 동시에 로컬 역할을 통해 개별 프로젝트 내에서 사용자 지정할 수 있습니다.

평가 중에는 클러스터 역할 바인딩과 로컬 역할 바인딩이 모두 사용됩니다. 예를 들면 다음과 같습니다.

역할은 일련의 리소스에서 수행할 수 있는 허용된 동사 집합인 정책 규칙 컬렉션입니다. OpenShift Container Platform에는 사용자 및 클러스터 전체 또는 로컬에 바인딩할 수 있는 기본 클러스터 역할 세트가 포함되어 있습니다.

프로젝트 관리자는 각각 CLI를 사용하여 연결된 동사 및 리소스의 매트릭스를 포함하여 역할을 시각화하여 로컬 역할 및 바인딩을 볼 수 있습니다.

프로젝트의 로컬 역할을 생성하는 방법을 알아봅니다.

$ oc auth reconcile -f <file> 1

사용자가 수행할 수 있는 작업을 제어하는 RBAC 리소스 외에도 OpenShift Container Platform은 Pod 에서 수행할 수 있는 작업과 액세스할 수 있는 작업을 제어하는 SCC( 보안 컨텍스트 제약 조건)를 제공합니다. 관리자는 CLI 를 사용하여 SCC를 관리할 수 있습니다.

SCC는 영구 스토리지에 대한 액세스를 관리하는 데도 매우 유용합니다.

SCC는 시스템에 적용하기 위해 Pod를 실행해야 하는 조건 집합을 정의하는 오브젝트입니다. 이를 통해 관리자는 다음을 제어할 수 있습니다.

기본적으로 7개의 SCC가 클러스터에 추가되며 CLI를 사용하여 클러스터 관리자가 볼 수 있습니다.

$ oc get scc

NAME               PRIV      CAPS      SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY   READONLYROOTFS   VOLUMES
anyuid             false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    10         false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
hostaccess         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim secret]
hostmount-anyuid   false     []        MustRunAs   RunAsAny           RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim secret]
hostnetwork        false     []        MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
nonroot            false     []        MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]
privileged         true      [*]       RunAsAny    RunAsAny           RunAsAny    RunAsAny    <none>     false            [*]
restricted         false     []        MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <none>     false            [configMap downwardAPI emptyDir persistentVolumeClaim secret]

CLI를 사용하여 클러스터 관리자가 각 SCC에 대한 정의도 볼 수 있습니다. 예를 들어 권한 있는 SCC의 경우 다음을 수행합니다.

$ oc get -o yaml --export scc/privileged

allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegedContainer: true
allowedCapabilities: 1
- '*'
apiVersion: v1
defaultAddCapabilities: [] 2
fsGroup: 3
  type: RunAsAny
groups: 4
- system:cluster-admins
- system:nodes
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: 'privileged allows access to all privileged and host
      features and the ability to run as any user, any group, any fsGroup, and with
      any SELinux context.  WARNING: this is the most relaxed SCC and should be used
      only for cluster administration. Grant with caution.'
  creationTimestamp: null
  name: privileged
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities: [] 5
runAsUser: 6
  type: RunAsAny
seLinuxContext: 7
  type: RunAsAny
seccompProfiles:
- '*'
supplementalGroups: 8
  type: RunAsAny
users: 9
- system:serviceaccount:default:registry
- system:serviceaccount:default:router
- system:serviceaccount:openshift-infra:build-controller
volumes:
- '*'

SCC의 users 및 groups 필드는 사용할 수 있는 SCC를 제어합니다. 기본적으로 클러스터 관리자, 노드 및 빌드 컨트롤러에는 권한 있는 SCC에 대한 액세스 권한이 부여됩니다. 인증된 모든 사용자에게는 제한된 SCC에 대한 액세스 권한이 부여됩니다.

Docker에는 포드의 각 컨테이너에 허용되는 기본 기능 목록이 있습니다. 컨테이너에서는 이 기본 목록의 기능을 사용하지만 Pod 매니페스트 작성자는 추가 기능을 요청하거나 일부 기본값을 삭제하여 이를 변경할 수 있습니다. allowedCapabilities,defaultAddCapabilities 및 requiredDropCapabilities 필드는 Pod에서 이러한 요청을 제어하고 요청 가능한 기능, 각 컨테이너에 추가해야 하는 기능 및 금지해야 하는 기능을 지정하는 데 사용됩니다.

권한 있는 SCC:

restricted SCC:

SCC는 포드에서 액세스할 수 있는 보안 기능을 제어하는 설정 및 전략으로 구성됩니다. 이 설정은 세 가지 범주로 분류됩니다.

volumes:
- flexVolume
allowedFlexVolumes:
- driver: example/lvm
- driver: example/cifs

rules:
- apiGroups:
  - security.openshift.io 1
  resources:
  - securitycontextconstraints 2
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
  resourceNames:
  - myPermittingSCC 3

OpenShift Container Platform 프로젝트 내에서 모든 네임스페이스 범위 리소스(타사 리소스 포함)에 대해 수행할 수 있는 동사를 확인할 수 있습니다. 다음을 실행합니다.

$ oc policy can-i --list --loglevel=8

출력은 정보를 수집하기 위해 수행할 API 요청을 결정하는 데 도움이 됩니다.

사용자가 읽을 수 있는 형식으로 정보를 다시 받으려면 다음을 실행합니다.

$ oc policy can-i --list

출력은 전체 목록을 제공합니다.

특정 동사 를 수행할 수 있는지 확인하려면 다음을 실행합니다.

$ oc policy can-i <verb> <resource>

사용자 범위는 지정된 범위에 대한 자세한 정보를 제공할 수 있습니다. 예를 들면 다음과 같습니다.

$ oc policy can-i <verb> <resource> --scopes=user:info

스토리지 관리는 컴퓨팅 리소스 관리와 다릅니다. OpenShift Container Platform에서는 Kubernetes PV(영구 볼륨) 프레임워크를 사용하여 클러스터 관리자가 클러스터의 영구 스토리지를 프로비저닝할 수 있습니다. 개발자는 PVC(영구 볼륨 클레임)를 사용하여 기본 스토리지 인프라를 구체적으로 잘 몰라도 PV 리소스를 요청할 수 있습니다.

PVC는 프로젝트에 고유하며 PV를 사용하는 수단으로 개발자가 생성 및 사용합니다. 자체 PV 리소스는 단일 프로젝트로 범위가 지정되지 않으며, 전체 OpenShift Container Platform 클러스터에서 공유되고 모든 프로젝트에서 요청할 수 있습니다. PV가 PVC에 바인딩된 후에는 해당 PV가 추가 PVC에 바인딩될 수 없습니다. 이는 바인딩 프로젝트(바인딩 프로젝트)에 바인딩된 PV의 범위를 단일 네임스페이스 로 지정하는 효과가 있습니다.

PV는 a PersistentVolume API 오브젝트로 정의되며, 이는 클러스터 관리자가 프로비저닝한 클러스터에서 기존 네트워크 스토리지 부분을 나타냅니다. 그리고 노드가 클러스터 리소스인 것과 마찬가지로 클러스터의 리소스입니다. PV는 볼륨과 같은 볼륨 플러그인이지만 PV를 사용하는 개별 Pod 와 관련된 라이프사이클이 있습니다. PV 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템에서 스토리지 구현의 세부 정보를 캡처합니다.

PVC는 PersistentVolumeClaim API 오브젝트에 의해 정의되며, 개발자의 스토리지 요청을 나타냅니다. Pod는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용하는 점에서 Pod와 유사합니다. 예를 들어 Pod는 특정 수준의 리소스(예: CPU 및 메모리)를 요청할 수 있지만 PVC는 특정 스토리지 용량 및 액세스 모드 (예: 읽기/쓰기 또는 여러 번 읽기 전용)를 요청할 수 있습니다.

PV는 클러스터의 리소스입니다. PVC는 그러한 리소스에 대한 요청이며, 리소스에 대한 클레임을 검사하는 역할을 합니다. PV와 PVC 간의 상호 작용에는 다음과 같은 라이프사이클이 있습니다.

각 PV에는 사양 및 상태가 포함됩니다. 이는 볼륨의 사양과 상태이고 예는 다음과 같습니다.

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv0003
  spec:
    capacity:
      storage: 5Gi
    accessModes:
      - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    nfs:
      path: /tmp
      server: 172.17.0.2

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
  annotations:
    volume.beta.kubernetes.io/mount-options: rw,nfsvers=4,noexec 1
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Retain
  claimRef:
    name: claim1
    namespace: default

각 PVC에는 사양 및 상태가 포함됩니다. 이는 클레임의 사양 및 상태입니다. 예를 들면 다음과 같습니다.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: gold

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

PV 및 PVC 사양에 API 필드를 포함하여 원시 블록 볼륨을 정적으로 프로비저닝할 수 있습니다.

블록 볼륨을 사용하려면 먼저 BlockVolume 기능 게이트를 활성화해야 합니다. 마스터의 기능 게이트를 활성화하려면 apiServerArguments 및 controllerArgument s에 feature-gate s 를 추가합니다. 노드의 기능 게이트를 활성화하려면 kubeletArguments에 feature-gates 를 추가합니다. 예를 들면 다음과 같습니다.

kubeletArguments:
   feature-gates:
     - BlockVolume=true

apiVersion: v1
kind: PersistentVolume
metadata:
  name: block-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  volumeMode: Block 1
  persistentVolumeReclaimPolicy: Retain
  fc:
    targetWWNs: ["50060e801049cfd1"]
    lun: 0
    readOnly: false

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block 1
  resources:
    requests:
      storage: 10Gi

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: [ "tail -f /dev/null" ]
      volumeDevices:  1
        - name: data
          devicePath: /dev/xvda 2
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: block-pvc 3

영구 스토리지 외에도 포드 및 컨테이너에는 작업을 위해 임시 또는 임시 로컬 스토리지가 필요할 수 있습니다. 이러한 임시 스토리지의 수명은 개별 Pod의 수명 이상으로 연장되지 않으며 이 임시 스토리지는 여러 Pod 사이에서 공유할 수 없습니다.

OpenShift Container Platform 3.10 이전에는 임시 로컬 스토리지가 컨테이너의 쓰기 가능한 계층, 로그 디렉터리, EmptyDir 볼륨을 사용하여 Pod에 노출되었습니다. Pod는 스크래치 공간, 캐싱 및 로그를 위해 임시 로컬 스토리지를 사용합니다. 로컬 스토리지 회계 및 격리 부족과 관련한 문제는 다음과 같습니다.

영구 볼륨과 달리 임시 스토리지는 비정형 및 공유되지만 시스템, 컨테이너 런타임, OpenShift Container Platform의 다른 용도 외에도 노드에서 실행되는 모든 포드 간에 실제 데이터가 아닌 공간을 구성합니다. 임시 스토리지 프레임워크를 사용하면 Pod에서 임시 로컬 스토리지 요구 사항을 지정하고 OpenShift Container Platform에서 적절한 Pod를 예약하고 로컬 스토리지를 과도하게 사용하지 않도록 노드를 보호할 수 있습니다.

임시 스토리지 프레임워크를 사용하면 관리자와 개발자가 이 로컬 스토리지를 더욱 더 쉽게 관리할 수 있지만 I/O 처리량 및 대기 시간과 관련해서는 보장을 하지 않습니다.

임시 로컬 스토리지는 항상 기본 파티션에서 사용할 수 있습니다. 기본 파티션을 생성하는 두 가지 기본 방법, 루트 및 런타임이 있습니다.

클러스터 관리자는 터미널이 아닌 상태에서 모든 Pod에서 임시 스토리지에 대한 제한 범위 및 요청 수를 정의하는 할당량을 설정하여 프로젝트 내에서 임시 스토리지를 관리할 수 있습니다. 개발자는 Pod 및 Container 수준에서 이 컴퓨팅 리소스에 대한 요청 및 제한을 설정 할 수도 있습니다.

/bin/df 를 임시 컨테이너 데이터가 있는 볼륨에서 임시 스토리지 사용을 모니터링하는 도구로, /var/lib/ origin 및 /var/lib/ docker 를 사용할 수 있습니다. 클러스터 관리자가 /var/lib/ docker를 별도의 디스크에 배치하는 경우 df 명령을 사용할 때 /var/lib/ origin 에만 사용 가능한 공간이 표시됩니다.

df -h 명령을 사용하여 /var/lib 에서 사용된 공간 및 사용 가능한 공간의 사람이 읽을 수 있는 값을 표시합니다.

$ df -h /var/lib

Filesystem  Size  Used Avail Use% Mounted on
/dev/sda1    69G   32G   34G  49% /

승인 제어 플러그인은 리소스가 유지되기 전에 마스터 API에 대한 요청을 가로채지만 요청이 인증 및 승인된 후입니다.

각 승인 제어 플러그인은 클러스터에 요청을 수락하기 전에 순서대로 실행됩니다. 시퀀스의 플러그인이 요청을 거부하면 전체 요청이 즉시 거부되고 최종 사용자에게 오류가 반환됩니다.

승인 제어 플러그인은 경우에 따라 시스템 구성 기본값을 적용하도록 들어오는 오브젝트를 수정할 수 있습니다. 또한 승인 제어 플러그인은 할당량 사용량 증가와 같은 작업을 수행하기 위해 요청 처리의 일부로 관련 리소스를 수정할 수 있습니다.

OpenShift Container Platform은 Kubernetes 및 OpenShift Container Platform 리소스에 단일 승인 체인을 사용합니다. 즉, 최상위 admissionConfig.pluginConfig.pluginConfig 요소에는 kubernetesMasterConfig.admissionConfig.pluginConfig 에 포함된 데 사용되는 승인 플러그인 구성이 포함될 수 있습니다.

kubernetesMasterConfig.admissionConfig.pluginConfig 를 이동하여 admissionConfig.pluginConfig 로 병합해야 합니다.

지원되는 모든 승인 플러그인은 단일 체인으로 정렬됩니다. admissionConfig.pluginOrderOverride 또는 kubernetesMasterConfig.admissionConfig.pluginOrderOverride 를 설정하지 않습니다. 대신 플러그인 특정 구성을 추가하거나 다음과 같이 DefaultAdmissionConfig 스탠자를 추가하여 기본적으로 꺼진 플러그인을 활성화합니다.

admissionConfig:
  pluginConfig:
    AlwaysPullImages: 1
      configuration:
        kind: DefaultAdmissionConfig
        apiVersion: v1
        disable: false 2

disable를 true 로 설정하면 기본값이 on인 승인 플러그인을 비활성화합니다.

클러스터 관리자는 다음과 같은 특정 동작을 제어하도록 일부 승인 제어 플러그인을 구성할 수 있습니다.

컨테이너를 사용하는 승인 컨트롤러도 init 컨테이너를 지원합니다.

기본 승인 컨트롤러 외에도 승인 체인의 일부로 승인 Webhook 를 사용할 수 있습니다.

승인 Webhook는 레이블을 삽입하기 위해 생성할 때 Pod를 변경하거나 승인 프로세스 중 Pod 구성의 특정 측면을 검증하도록 웹 후크 서버를 호출합니다.

승인 Webhook는 리소스를 지속성하기 전에 마스터 API로 요청을 가로채지만 요청이 인증 및 승인된 후입니다.

OpenShift Container Platform에서는 API 승인 체인 중에 웹 후크 서버를 호출하는 승인 Webhook 오브젝트를 사용할 수 있습니다.

다음 두 가지 유형의 승인 Webhook 오브젝트를 구성할 수 있습니다.

웹 후크 및 외부 웹 후크 서버를 구성하는 것은 이 문서의 범위를 벗어납니다. 그러나 OpenShift Container Platform에서 제대로 작동하려면 Webhook가 인터페이스를 준수해야 합니다.

오브젝트가 인스턴스화되면 OpenShift Container Platform은 API 호출을 수행하여 오브젝트를 허용합니다. 승인 프로세스 중에 승인 컨트롤러는 Webhook 를 호출하여 선호도 레이블 삽입과 같은 작업을 수행할 수 있습니다. 승인 프로세스가 끝나면 검증 승인 컨트롤러에서 Webhook를 호출하여 선호도 레이블 확인과 같은 오브젝트가 올바르게 구성되었는지 확인할 수 있습니다. 검증이 통과되면 OpenShift Container Platform에서 구성된 대로 오브젝트를 스케줄링합니다.

API 요청이 도착하면 변경 또는 검증 승인 컨트롤러는 구성의 외부 Webhook 목록을 사용하여 병렬로 호출합니다.

승인 컨트롤러와 웹 후크 서버 간의 통신은 TLS를 사용하여 보안을 설정해야 합니다. CA 인증서를 생성하고 인증서를 사용하여 웹 후크 서버에서 사용하는 서버 인증서에 서명합니다. PEM 형식의 CA 인증서는 Service Serving 인증서 비밀 과 같은 메커니즘을 사용하여 승인 컨트롤러에 제공됩니다.

다음 다이어그램에서는 여러 웹 후크를 호출하는 두 개의 승인 Webhook가 있는 이 프로세스를 보여줍니다.

승인 Webhook의 간단한 사용 사례는 리소스의 구문 검증입니다. 예를 들어 모든 Pod에 공통 레이블 세트가 있어야 하는 인프라가 있으며, Pod에 해당 라벨이 없는 경우 Pod가 유지되지 않도록 합니다. 이러한 라벨과 다른 웹 후크를 삽입하도록 웹 후크를 작성하여 레이블이 있는지 확인할 수 있습니다. 그런 다음 OpenShift Container Platform은 라벨이 있는 Pod를 예약하고 유효성 검사를 통과하며 누락된 라벨으로 인해 전달되지 않는 Pod를 거부합니다.

일반적인 사용 사례는 다음과 같습니다.

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: MutatingWebhookConfiguration 1
  metadata:
    name: <controller_name> 2
  webhooks:
  - name: <webhook_name> 3
    clientConfig: 4
      service:
        namespace:  5
        name: 6
       path: <webhook_url> 7
      caBundle: <cert> 8
    rules: 9
    - operations: 10
      - <operation>
      apiGroups:
      - ""
      apiVersions:
      - "*"
      resources:
      - <resource>
    failurePolicy: <policy> 11

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: ValidatingWebhookConfiguration 1
  metadata:
    name: <controller_name> 2
  webhooks:
  - name: <webhook_name> 3
    clientConfig: 4
      service:
        namespace: default  5
        name: kubernetes 6
       path: <webhook_url> 7
      caBundle: <cert> 8
    rules: 9
    - operations: 10
      - <operation>
      apiGroups:
      - ""
      apiVersions:
      - "*"
      resources:
      - <resource>
    failurePolicy: <policy> 11

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: ValidatingWebhookConfiguration
  metadata:
    name: namespacereservations.admission.online.openshift.io
  webhooks:
  - name: namespacereservations.admission.online.openshift.io
    clientConfig:
      service:
        namespace: default
        name: webhooks
       path: /apis/admission.online.openshift.io/v1beta1/namespacereservations
      caBundle: KUBE_CA_HERE
    rules:
    - operations:
      - CREATE
      apiGroups:
      - ""
      apiVersions:
      - "b1"
      resources:
      - namespaces
    failurePolicy: Ignore

apiVersion: v1
kind: Pod
metadata:
  labels:
    role: webhook
  name: webhook
spec:
  containers:
    - name: webhook
      image: myrepo/myimage:latest
      imagePullPolicy: IfNotPresent
      ports:
- containerPort: 8000

apiVersion: v1
kind: Service
metadata:
  labels:
    role: webhook
  name: webhook
spec:
  ports:
    - port: 443
      targetPort: 8000
  selector:
role: webhook

제한 범위는 Kubernetes 네임스페이스 의 리소스에 배치된 최소/최대 제한을 적용하는 메커니즘을 제공합니다.

제한 범위를 네임스페이스에 추가하여 개별 Pod 또는 컨테이너에서 사용하는 최소 및 최대 CPU 및 메모리 양을 적용할 수 있습니다.

CPU 및 메모리 제한의 경우 max 값을 지정하지만 LimitRange 오브젝트에 min 제한을 지정하지 않으면 리소스에서 max 값보다 큰 CPU/메모리 리소스를 사용할 수 있습니다.

Kubernetes는 네임스페이스에 생성된 오브젝트 수와 네임스페이스 의 오브젝트에서 요청된 총 리소스 양을 모두 제한할 수 있습니다. 따라서 한 팀이 다른 클러스터 리소스를 사용하지 못하게 하는 메커니즘으로 각각 네임스페이스에서 여러 팀이 단일 Kubernetes 클러스터를 공유할 수 있습니다.

ResourceQuota 에 대한자세한 내용은 클러스터 관리를 참조하십시오.

Kubernetes 리소스는 포드 또는 컨테이너에서 요청하거나, 할당하거나, 사용할 수 있는 항목입니다. 예를 들어 메모리(RAM), CPU, 디스크 시간 및 네트워크 대역폭이 있습니다.

자세한 내용은 개발자 가이드를 참조하십시오.

시크릿 은 키, 암호 및 인증서와 같은 중요한 정보를 위한 스토리지입니다. 원하는 포드에서 액세스할 수 있지만 정의와 별도로 포함됩니다.

영구 볼륨은 클러스터 관리자가 프로비저닝하는 인프라의 오브젝트(PersistentVolume)입니다. 영구 볼륨은 상태 저장 애플리케이션을 위한 지속적 스토리지를 제공합니다.

PersistentVolumeClaim 오브젝트는 Pod 작성자의 스토리지 요청입니다. Kubernetes는 사용 가능한 볼륨 풀에 대한 클레임과 일치하고 함께 바인딩합니다. 그런 다음 Pod에서 클레임을 볼륨으로 사용합니다. Kubernetes는 볼륨을 필요한 Pod와 동일한 노드에서 사용할 수 있는지 확인합니다.

Kubernetes는 pod가 네트워크를 통해 서로 연결할 수 있도록 하며 각 pod에 내부 네트워크의 IP 주소를 할당합니다. 이렇게 하면 pod 내의 모든 컨테이너가 마치 동일한 호스트에 있는 것처럼 작동합니다. 각 pod에 고유 IP 주소를 부여하면 포트 할당, 네트워킹, 이름 지정, 서비스 검색, 로드 밸런싱, 애플리케이션 구성 및 마이그레이션 등 다양한 업무를 할 때 pod를 물리적 호스트 또는 가상 머신처럼 취급할 수 있습니다.

포드 간 링크를 생성할 필요가 없으며 포드가 IP 주소를 사용하여 직접 서로 통신하지 않는 것이 좋습니다. 대신 서비스를 생성한 다음 서비스와 상호 작용하는 것이 좋습니다.

frontend 포드가 백엔드 서비스와 통신하기 위해 프론트엔드 및 백엔드 서비스와 같은 여러 서비스를 실행하는 경우 사용자 이름, 서비스 IP 등에 대한 환경 변수가 생성됩니다. 서비스를 삭제하고 다시 생성하면 새 IP 주소를 서비스에 할당할 수 있으며 서비스 IP 환경 변수의 업데이트된 값을 가져오기 위해 프론트엔드 포드를 다시 생성해야 합니다. 또한 서비스 IP가 올바르게 생성되고 프론트엔드 포드에 환경 변수로 제공할 수 있도록 백엔드 서비스를 생성한 후 frontend 포드에 생성해야 합니다.

이러한 이유로 서비스 DNS는 물론 서비스 IP/포트를 통해서도 서비스를 이용할 수 있도록 OpenShift Container Platform에 DNS를 내장했습니다. OpenShift Container Platform은 서비스의 DNS 쿼리에 응답하는 마스터에서 SkyDNS 를 실행하여 분할된 DNS를 지원합니다. 마스터는 기본적으로 포트 53을 수신 대기합니다.

노드가 시작되면 다음 메시지는 Kubelet이 마스터로 올바르게 확인되었음을 나타냅니다.

0308 19:51:03.118430    4484 node.go:197] Started Kubelet for node
openshiftdev.local, server at 0.0.0.0:10250
I0308 19:51:03.118459    4484 node.go:199]   Kubelet is setting 10.0.2.15 as a
DNS nameserver for domain "local"

두 번째 메시지가 표시되지 않으면 Kubernetes 서비스를 사용할 수 없습니다.

노드 호스트에서 각 컨테이너의 이름 서버에는 앞에 마스터 이름이 추가되고 컨테이너의 기본 검색 도메인은 <pod_namespace>.cluster.local 이 됩니다. 그런 다음 컨테이너는 Docker 형식 컨테이너의 기본 동작인 노드의 다른 이름 서버 앞에 이름 서버 쿼리를 마스터로 보냅니다. 마스터는 다음 양식이 있는 .cluster.local 도메인의 쿼리에 응답합니다.

이렇게 하면 서비스에 대한 새 IP를 생성하는 새 서비스를 가져오기 위해 프론트엔드 포드를 다시 시작하지 않아도 됩니다. 또한 포드에서 서비스 DNS를 사용할 수 있기 때문에 환경 변수를 사용할 필요가 없습니다. 또한 DNS는 변경되지 않으므로 구성 파일에서 데이터베이스 서비스를 db.local 로 참조할 수 있습니다. 조회가 서비스 IP로 확인되고, 프론트엔드 포드보다 먼저 백엔드 서비스를 만들 필요가 없기 때문에 와일드카드 조회도 지원됩니다. 따라서 서비스 이름(따라서 DNS)이 초기 상태로 설정되어 있기 때문입니다.

이 DNS 구조는 포털 IP가 서비스에 할당되지 않고 kube-proxy가 해당 엔드포인트에 라우팅을 로드 밸런싱하지 않거나 라우팅을 제공하는 헤드리스 서비스도 다룹니다. 서비스 DNS를 계속 사용하고 서비스의 각 포드에 하나씩 여러 A 레코드로 응답할 수 있으므로 클라이언트가 각 포드 간에 라운드 로빈할 수 있습니다.

OpenShift Container Platform에서는 소프트웨어 정의 네트워킹(SDN) 접근법을 사용하여 OpenShift Container Platform 클러스터 전체의 pod 간 통신이 가능한 통합 클러스터 네트워크를 제공합니다. 이 pod 네트워크는 OVS(Open vSwitch)를 사용하여 오버레이 네트워크를 구성하는 OpenShift SDN에 의해 설정 및 유지 관리됩니다.

OpenShift SDN은 Pod 네트워크를 구성하는 데 필요한 세 가지 SDN 플러그인을 제공합니다.

OpenShift Container Platform 마스터에서 OpenShift SDN은 etcd 에 저장된 노드 레지스트리를 유지 관리합니다. 시스템 관리자가 노드를 등록하면 OpenShift SDN에서 클러스터 네트워크에서 사용되지 않은 서브넷을 할당하고 이 서브넷을 레지스트리에 저장합니다. 노드가 삭제되면 OpenShift SDN은 레지스트리에서 서브넷을 삭제하고 사용 가능한 서브넷을 다시 할당할 수 있다고 간주합니다.

기본 구성에서 클러스터 네트워크는 10.128.0.0/14 네트워크(예: 10.128.0.0 - 10.131.255.255.255)이며 노드에는 /23 서브넷(예: 10.128.0.0/23,10.128.2.0/23,10.128.4.0/23 등)이 할당됩니다. 즉, 클러스터 네트워크에는 노드에 할당할 수 있는 512개의 서브넷이 있으며 지정된 노드에는 실행 중인 컨테이너에 할당할 수 있는 주소가 할당됩니다. 는 호스트 서브넷 크기이므로 클러스터 네트워크의 크기 및 주소 범위를 구성할 수 있습니다.

마스터의 OpenShift SDN은 클러스터 네트워크에 액세스할 수 있도록 로컬(마스터) 호스트를 구성하지 않습니다. 결과적으로 마스터 호스트는 노드로 실행되지 않는 한 클러스터 네트워크를 통해 포드에 액세스할 수 없습니다.

ovs-multitenant 플러그인을 사용하는 경우 OpenShift SDN 마스터는 프로젝트의 생성 및 삭제를 감시하고 나중에 노드에서 트래픽을 격리하는 데 사용하는 VXLAN VNID를 할당합니다.

노드에서 OpenShift SDN은 먼저 마스터가 노드에 서브넷을 할당하도록 앞에서 설명한 레지스트리에서 SDN 마스터에 로컬 호스트를 등록합니다.

그런 다음 OpenShift SDN은 세 개의 네트워크 장치를 만들고 구성합니다.

호스트에서 포드를 시작할 때마다 OpenShift SDN은 다음과 같습니다.

OpenShift SDN 노드는 SDN 마스터의 서브넷 업데이트도 감시합니다. 새 서브넷이 추가되면 노드는 br0 에 OpenFlow 규칙을 추가하여 원격 서브넷의 대상 IP 주소가 있는 패킷이 vxlan0 (br 0의 포트 1)으로 이동하므로 네트워크로 나갑니다. ovs-subnet 플러그인은 VNID 0을 사용하여 VXLAN의 모든 패킷을 전송하지만 ovs-multitenant 플러그인은 소스 컨테이너에 적절한 VNID를 사용합니다.

컨테이너 A의 eth0에 대한 피어 가상 이더넷 장치의 이름은 vethA이고 컨테이너 B의 eth0 에 대한 피어 가상 이더넷 장치의 이름은 veth B 인 두 개의 컨테이너 A와 B가 있다고 가정합니다.

이제 먼저 컨테이너 A가 로컬 호스트에 있고 컨테이너 B도 로컬 호스트에 있다고 가정합니다. 컨테이너 A에서 컨테이너 B로의 패킷 흐름은 다음과 같습니다.

eth0 (A의 netns에서) → vethA → br0 → vethB → eth0 (B의 netns에서)

다음으로 컨테이너 A가 로컬 호스트에 있고 컨테이너 B가 클러스터 네트워크의 원격 호스트에 있다고 가정합니다. 컨테이너 A에서 컨테이너 B로의 패킷 흐름은 다음과 같습니다.

eth0 (A의 netns에서) → vethA → br0 → vxlan0 → 네트워크 ^[1] → vxlan0 → br0 → vethB → eth0 (B의 netns에서)

마지막으로 컨테이너 A가 외부 호스트에 연결하는 경우 트래픽은 다음과 같습니다.

eth0 (A의 netns에서) → vethA → br0 → tun0 → (NAT) → eth0 (물리 장치) → 인터넷

대부분의 패킷 전달 결정은 플러그인 네트워크 아키텍처를 간소화하고 유연한 라우팅을 제공하는 OVS 브리지 br0 에서 OpenFlow 규칙을 사용하여 수행됩니다. ovs-multitenant 플러그인의 경우 적용 가능한 네트워크 격리 도 제공합니다.

ovs-multitenant 플러그인을 사용하여 네트워크 격리를 수행할 수 있습니다. 패킷이 기본이 아닌 프로젝트에 할당된 포드를 종료하면 OVS 브리지 br0 은 프로젝트의 할당된 VNID와 패킷하는 태그입니다. 패킷이 노드의 클러스터 서브넷에 있는 다른 IP 주소로 전달되는 경우 OVS 브리지는 VNID가 일치하는 경우에만 패킷이 대상 포드로 전달되도록 허용합니다.

VXLAN 터널을 통해 다른 노드에서 패킷을 수신하면 터널 ID가 VNID로 사용되며 OVS 브리지는 터널 ID가 대상 포드의 VNID와 일치하는 경우에만 패킷이 로컬 포드로 전달되도록 허용합니다.

다른 클러스터 서브넷으로 향하는 패킷은 VNID로 태그가 지정되며 클러스터 서브넷을 소유하는 노드의 터널 대상 주소가 있는 VXLAN 터널로 전달됩니다.

앞에서 설명한 대로 VNID 0은 할당된 모든 Pod에 VNID 0을 입력할 수 있는 해당 트래픽에서 권한이 있으며 VNID 0을 사용하는 트래픽은 모든 Pod를 입력할 수 있습니다. 기본 OpenShift Container Platform 프로젝트만 VNID 0으로 할당됩니다. 다른 모든 프로젝트에는 격리 가능 고유 VNID가 할당됩니다. 클러스터 관리자는 관리자 CLI 를 사용하여 프로젝트의 포드 네트워크를 선택적으로 제어할 수 있습니다.

OpenShift SDN은 Ansible 기반 설치 절차의 일부로 기본적으로 설치 및 구성됩니다. 자세한 내용은 OpenShift SDN 섹션을 참조하십시오.

Kuryr (또는 구체적으로 Kuryr-Kubernetes)는 CNI 및 OpenStack Neutron 을 사용하여 빌드된 SDN 솔루션입니다. 이 솔루션의 장점은 광범위한 Neutron SDN 백엔드를 사용하고 Kubernetes 포드와 OpenStack VM(가상 시스템) 간에 상호 연결을 제공할 수 있다는 것입니다.

Kuryr-Kubernetes 및 OpenShift Container Platform 통합은 주로 OpenStack VM에서 실행되는 OpenShift Container Platform 클러스터를 위해 설계되었습니다.

HAProxy 템플릿 라우터 구현은 템플릿 라우터 플러그인의 참조 구현입니다. openshift3/ose-haproxy-router 리포지토리를 사용하여 템플릿 라우터 플러그인과 함께 HAProxy 인스턴스를 실행합니다.

템플릿 라우터에는 다음 두 가지 구성 요소가 있습니다.

컨트롤러 및 HAProxy는 포드 내부에 있으며 배포 구성에서 관리합니다. 라우터를 설정하는 프로세스는 oc adm router 명령으로 자동화됩니다.

컨트롤러는 HAProxy 상태를 비롯하여 변경 사항이 있는지 경로 및 엔드포인트를 감시합니다. 변경 사항이 감지되면 새 haproxy-config 파일을 빌드하고 HAProxy를 다시 시작합니다. haproxy-config 파일은 라우터의 템플릿 파일과 OpenShift Container Platform의 정보를 기반으로 구성됩니다.

HAProxy 템플릿 파일은 OpenShift Container Platform에서 현재 지원하지 않는 기능을 지원하기 위해 필요에 따라 사용자 지정할 수 있습니다. HAProxy 설명서는 HAProxy 에서 지원하는 모든 기능을 설명합니다.

다음 다이어그램에서는 데이터가 마스터에서 플러그인을 거쳐 HAProxy 구성으로 이동하는 방법을 보여줍니다.

그림 5.4. HAProxy 라우터 데이터 흐름

HAProxy 템플릿 라우터 지표

HAProxy 라우터는 외부 지표 수집 및 집계 시스템(예: Prometheus, statsd)에서 사용할 수 있도록 Prometheus 형식으로 지표를 노출하거나 게시합니다. 라우터는 HAProxy CSV 형식 지표를 제공하거나 라우터 지표를 전혀 제공하지 않도록 구성할 수 있습니다.

지표는 라우터 컨트롤러와 5초마다 HAProxy에서 수집됩니다. 라우터 지표 카운터는 라우터가 배포될 때 0으로 시작되고 시간이 지남에 따라 증가합니다. haproxy가 다시 로드될 때마다 HAProxy 지표 카운터가 0으로 재설정됩니다. 라우터는 각 프론트엔드, 백엔드 및 서버에 대한 HAProxy 통계를 수집합니다. 500대 이상의 서버가 있는 경우 리소스 사용량을 줄이기 위해 백엔드에는 여러 서버가 있을 수 있으므로 서버 대신 백엔드가 보고됩니다.

통계는 사용 가능한 HAProxy 통계의 하위 집합입니다.

다음 HAProxy 지표는 주기적으로 수집되어 Prometheus 형식으로 변환됩니다. 프런트 엔드마다 "F" 카운터가 수집됩니다. 각 백엔드에 대해 카운터를 수집하고 각 서버에 대해 "S" 서버 카운터를 수집하면 됩니다. 그렇지 않으면 각 백엔드에 대해 "B" 카운터가 수집되어 서버 카운터가 수집되지 않습니다.

자세한 내용은 라우터 환경 변수를 참조하십시오.

다음 표에서 다음을 수행합니다.

열 1 - HAProxy CSV 통계의 인덱스

2열

열 3 - 카운터

열 4 - 카운터 설명

라우터 컨트롤러는 다음 항목을 스크랩합니다. Prometheus 형식 지표만 사용할 수 있습니다.

OpenShift Container Platform은 Kubernetes에 내장된 기능을 활용하여 포드로의 포트 전달을 지원합니다. 이는 SPDY 또는 HTTP /2와 같은 멀티플렉싱된 스트리밍 프로토콜과 함께 HTTP 를 사용하여 구현됩니다.

개발자는 CLI를 사용하여 포드에 포트 전달을 수행할 수 있습니다. CLI는 사용자가 지정한 각 로컬 포트에서 수신 대기하여 설명된 프로토콜을 통해 전달합니다.

Kubelet은 클라이언트의 포트 전달 요청을 처리합니다. 요청을 수신하면 응답을 업그레이드하고 클라이언트가 포트 전달 스트림을 생성할 때까지 기다립니다. 새 스트림을 수신하면 스트림과 Pod의 포트 간에 데이터를 복사합니다.

구조적으로 Pod의 포트로 전달할 수 있는 옵션이 있습니다. 현재 OpenShift Container Platform에서 지원되는 구현은 노드 호스트에서 직접 nsenter 를 호출하여 Pod의 네트워크 네임스페이스를 입력한 다음 socat 을 호출하여 스트림과 Pod 포트 간 데이터를 복사합니다. 그러나 사용자 정의 구현에는 nsenter 및 socat 을 실행하는 "helper" Pod를 실행할 수 있으므로 이러한 바이너리를 호스트에 설치할 필요가 없습니다.

OpenShift Container Platform은 Kubernetes에 내장된 기능을 활용하여 컨테이너에서 명령 실행을 지원합니다. 이는 SPDY 또는 HTTP /2와 같은 멀티플렉싱된 스트리밍 프로토콜과 함께 HTTP 를 사용하여 구현됩니다.

개발자는 CLI를 사용하여 컨테이너에서 원격 명령을 실행할 수 있습니다.

Kubelet은 클라이언트의 원격 실행 요청을 처리합니다. 요청을 수신하면 응답이 업그레이드되고 요청 헤더를 평가하여 수신할 스트림(stdin, stdout 및/또는 stderr)을결정하고 클라이언트가 스트림을 생성할 때까지 기다립니다.

Kubelet은 모든 스트림을 수신한 후 컨테이너에서 명령을 실행하여 스트림과 명령의 stdin, stdout 및 stderr 간에 적절하게 복사합니다. 명령이 종료되면 Kubelet은 업그레이드된 연결과 기본 연결을 종료합니다.

구조적으로는 컨테이너에서 명령을 실행할 수 있는 옵션이 있습니다. 현재 OpenShift Container Platform에서 지원되는 구현은 명령을 실행하기 전에 노드 호스트에서 직접 nsenter 를 호출하여 컨테이너의 네임스페이스를 입력합니다. 그러나 사용자 정의 구현에는 docker exec 를 사용하거나 nsenter 를 실행하는 "helper" 컨테이너를 실행하여 nsenter 가 호스트에 설치해야 하는 필수 바이너리가 아닙니다.

OpenShift Container Platform 경로는 호스트 이름(예: www.example.com) 에 서비스를 노출하므로 외부 클라이언트가 이름으로 연결할 수 있습니다.

호스트 이름의 DNS 확인은 라우팅과 별도로 처리됩니다. 관리자는 OpenShift Container Platform 라우터를 실행 중인 OpenShift Container Platform 노드로 확인되는 DNS 와일드카드 항목을 구성했을 수 있습니다. 다른 호스트 이름을 사용하는 경우 라우터를 실행 중인 노드를 확인하기 위해 해당 DNS 레코드를 독립적으로 수정해야 할 수 있습니다.

각 경로는 이름( 63자), 서비스 선택기 및 선택적 보안 구성으로 구성됩니다.

OpenShift Container Platform 관리자는 OpenShift Container Platform 클러스터의 노드에 라우터 를 배포할 수 있으므로 개발자가 생성한 경로를 외부 클라이언트에서 사용할 수 있습니다. OpenShift Container Platform의 라우팅 계층은 플러그형이며, 기본적으로 여러 라우터 플러그인이 제공되고 지원됩니다.

라우터는 서비스 선택기를 사용하여 서비스를 지원하는 서비스와 엔드포인트를 찾습니다. 라우터와 서비스 모두 로드 밸런싱을 제공하는 경우 OpenShift Container Platform은 라우터 로드 밸런싱을 사용합니다. 라우터는 서비스의 IP 주소에서 관련 변경 사항을 감지하고 그에 따라 구성을 조정합니다. 이 기능은 사용자 지정 라우터를 통해 API 오브젝트를 외부 라우팅 솔루션으로 변경하는 데 유용합니다.

요청 경로는 호스트 이름의 DNS를 하나 이상의 라우터로 확인하는 것으로 시작됩니다. 제안된 방법은 여러 라우터 인스턴스에서 지원하는 하나 이상의 가상 IP(VIP) 주소를 가리키는 와일드카드 DNS 항목을 사용하여 클라우드 도메인을 정의하는 것입니다. 클라우드 도메인 외부의 이름과 주소를 사용하는 경로에는 개별 DNS 항목을 구성해야 합니다.

라우터보다 VIP 주소가 적으면 주소 수에 해당하는 라우터가 활성 상태이며 나머지는 패시브 입니다. 패시브 라우터는 핫-대기 라우터라고도 합니다. 예를 들어 VIP 주소 2개와 라우터 3개가 있는 경우 "active-active-passive" 구성이 있습니다. 라우터 VIP 구성에 대한 자세한 내용은 High Availability 를 참조하십시오.

경로는 라우터 집합 간에 분할 할 수 있습니다. 관리자는 클러스터 전체에서 분할을 설정할 수 있으며 사용자는 프로젝트에서 네임스페이스에 대한 분할을 설정할 수 있습니다. 운영자가 분할을 통해 여러 라우터 그룹을 정의할 수 있습니다. 그룹의 각 라우터는 트래픽의 하위 집합만 제공합니다.

OpenShift Container Platform 라우터는 라우터에 직접 구분 정보를 전달하는 프로토콜을 통해 외부 호스트 이름 매핑 및 서비스 엔드포인트의 부하 분산을 제공합니다. 라우터에서 보낼 위치를 결정하려면 호스트 이름이 프로토콜에 있어야 합니다.

라우터 플러그인은 기본적으로 호스트 포트 80(HTTP) 및 443(HTTPS)에 바인딩할 수 있다고 가정합니다. 즉, 라우터를 해당 포트가 사용하지 않는 노드에 배치해야 합니다. 또는 ROUTER_SERVICE_ HTTP_PORT 및 ROUTER_SERVICE_HTTPS_PORT 환경 변수를 설정하여 다른 포트에서 수신 대기하도록 라우터를 구성할 수 있습니다.

라우터가 호스트 노드의 포트에 바인딩되므로 라우터가 호스트 네트워킹(기본값)을 사용하는 경우 해당 포트에서 수신 대기하는 하나의 라우터만 각 노드에 있을 수 있습니다. 클러스터 네트워킹은 모든 라우터가 클러스터의 모든 포드에 액세스할 수 있도록 구성됩니다.

라우터는 다음과 같은 프로토콜을 지원합니다.

보안 연결을 설정하려면 클라이언트와 서버에 공통된 암호를 협상해야 합니다. 시간이 지남에 따라 더욱 새롭고 안전한 암호를 사용할 수 있게 되며 클라이언트 소프트웨어로 통합됩니다. 이전 클라이언트가 사용되지 않게 되면 더 오래되고 안전하지 않은 암호를 삭제할 수 있습니다. 기본적으로 라우터는 사용 가능한 광범위한 클라이언트를 지원합니다. 원하는 클라이언트를 지원하고 덜 안전한 암호를 포함하지 않는 선택한 암호 집합을 사용하도록 라우터를 구성할 수 있습니다.

사용 가능한 라우터 플러그인은 사용 가능한 라우터 플러그인 섹션을 참조하십시오.

이러한 라우터를 배포하는 방법은 라우터 배포에서 확인할 수 있습니다.

고정 세션 구현은 기본 라우터 구성에 따라 달라집니다. 기본 HAProxy 템플릿은 소스 IP를 기반으로 균형을 조정하는 balance source 지시문을 사용하여 고정 세션을 구현합니다. 또한 템플릿 라우터 플러그인에서는 서비스 이름과 네임스페이스를 기본 구현에 제공합니다. 이 명령은 피어 집합 간에 동기화되는 stick-tables 구현과 같은 고급 구성에 사용할 수 있습니다.

고정 세션을 사용하면 사용자 세션의 모든 트래픽이 동일한 포드로 이동하여 더 나은 사용자 환경을 만들 수 있습니다. 사용자의 요청을 충족하는 동안 Pod는 후속 요청에 사용할 수 있는 데이터를 캐시합니다. 예를 들어 5개의 백엔드 포드와 부하 분산 라우터가 있는 클러스터의 경우 동일한 포드가 이를 처리하는 라우터와 관계없이 동일한 웹 브라우저에서 웹 트래픽을 수신하는지 확인할 수 있습니다.

동일한 Pod로 라우팅 트래픽을 반환하는 동안은 보장할 수 없습니다. 그러나 HTTP 헤더를 사용하여 마지막 연결에서 사용되는 Pod를 판별하기 위해 쿠키를 설정할 수 있습니다. 사용자가 애플리케이션에 다른 요청을 보내면 브라우저가 쿠키를 다시 전송하고 라우터는 트래픽을 보낼 위치를 알고 있습니다.

클러스터 관리자는 다른 연결과 별도로 패스스루 경로의 고정을 해제하거나 고정을 완전히 끌 수 있습니다.

기본적으로 패스스루 경로에 대한 고정 세션은 소스 로드 밸런싱 전략을 사용하여 구현됩니다. ROUTER_TCP_BALANCE_SCHEME환경 변수를 사용하고 haproxy.router.openshift.io/balance 경로 특정 주석을 사용하여 개별 경로에 대해 모든 통과 경로에 대해 기본값을 변경할 수 있습니다.

다른 유형의 경로는 기본적으로 leastconn 부하 분산 전략을 사용하며, ROUTER_LOAD_BALANCE_ALGORITHM 환경 변수를 사용하여 변경할 수 있습니다. haproxy.router.openshift.io/balance 경로 특정 주석을 사용하여 개별 경로에 대해 변경할 수 있습니다.

또한 템플릿 라우터 플러그인에서는 서비스 이름과 네임스페이스를 기본 구현에 제공합니다. 이는 피어 집합 간에 동기화되는 stick-tables 구현과 같은 고급 구성에 사용할 수 있습니다.

이 라우터 구현에 대한 특정 구성은 라우터 컨테이너의 /var/lib/haproxy/conf 디렉터리에 있는 haproxy-config.template 파일에 저장됩니다. 파일을 사용자 지정할 수 있습니다.

이 섹션에 설명된 모든 항목에 대해 라우터의 배포 구성에 환경 변수를 설정하여 구성을 변경하거나 oc set env 명령을 사용할 수 있습니다.

$ oc set env <object_type>/<object_name> KEY1=VALUE1 KEY2=VALUE2

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

$ oc set env dc/router ROUTER_SYSLOG_ADDRESS=127.0.0.1 ROUTER_LOG_LEVEL=debug