Red Hat OpenShift on IBM Cloud에서 실행할 수 있는 앱의 유형은 무엇입니까?

Stateless 앱

Stateless 앱은 Kubernetes와 같은 클라우드 네이티브 환경에서 선호됩니다. 종속성을 선언하고, 코드와 별도로 구성을 저장하고, 앱에 결합하는 대신 연결된 리소스로서 데이터베이스와 같은 지원 서비스를 처리하므로 쉽게 마이그레이션하고 스케일링할 수 있습니다. 앱 팟(Pod)에는 지속적 데이터 스토리지 또는 고정 네트워크 IP 주소가 필요하지 않으며, 이에 따라 팟(Pod)은 워크로드 요구사항에 응답하여 종료되고, 다시 스케줄되고, 스케일링될 수 있습니다. 앱은 지속적 데이터에 대해 Database-as-a-Service를 사용하고 NodePort, 로드 밸런서 또는 Ingress 서비스를 사용하여 고정 IP 주소의 워크로드를 노출합니다.

Stateful 앱

팟(Pod)에는 지속적 데이터 및 고정 네트워크 ID가 필요하므로 Stateful 앱은 설정하고, 관리하고, 스케일링하기가 Stateless 앱보다 더욱 복잡합니다. Stateful 앱은 주로 데이터베이스 또는 기타 분산된 데이터 집약적인 워크로드입니다. 여기서, 처리가 효율적일수록 데이터 자체에 더욱 가깝습니다. Stateful 앱을 배치하려면 지속적 스토리지를 설정하고 지속적 볼륨을 StatefulSet 오브젝트에서 제어하는 팟(Pod)에 마운트해야 합니다. 파일, 블록 또는 오브젝트 스토리지를 Stateful 세트를 위한 지속적 스토리지에 추가하도록 선택할 수 있습니다. 베어 메탈 워커 노드에 Portworx 를 베어 메탈 워커 노드에 설치하고 Portworx 를 고가용성 소프트웨어 정의 스토리지 솔루션으로 사용하여 스테이트풀 앱의 영구 스토리지를 관리할 수도 있습니다. 스테이트풀 세트의 작동 방식에 대한 자세한 내용은 Kubernetes 문서를 참조하세요.

Stateless인 클라우드 네이티브 앱을 개발하기 위한 가이드라인은 무엇입니까?

다음과 같이 요약된 12가지 요소에 걸쳐 앱 개발 방법을 고려하는 언어 중립적인 방법론인 12요소 앱을 확인해 보세요.

1. 코드 베이스: 배치를 위해 버전 제어 시스템에서 단일 코드 베이스를 사용하십시오. 컨테이너 배치에 맞게 이미지를 가져오는 경우 latest를 사용하는 대신 테스트된 이미지 태그를 지정하십시오.
2. 종속성: 외부 종속성을 명시적으로 선언하고 격리합니다.
3. 구성: 코드가 아닌 환경 변수에서 배치별 특정 구성을 저장합니다.
4. 지원 서비스: 연결되거나 대체 가능한 리소스로서 데이터 저장소 또는 메시지 큐와 같은 지원 서비스를 처리합니다.
5. 앱 단계: 엄격하게 분리하여 build, release, run과 같은 명백한 단계로 빌드합니다.
6. 프로세스: 데이터를 저장하기 위해 아무 것도 공유하지 않고 지속적 스토리지를 사용하는 하나 이상의 Stateless 프로세스로 실행합니다.
7. 포트 바인딩: 포트 바인딩은 내장되어 있으며 명확한 호스트 및 포트에서 서비스 엔드포인트를 제공합니다.
8. 동시성: 복제본 및 수평 스케일링과 같은 프로세스 인스턴스를 통해 앱을 관리하고 스케일링합니다. 사용자 배치에 맞게 리소스 요청 및 한계를 설정하십시오. Calico 네트워크 정책은 대역폭을 제한할 수 없습니다.
9. 일회성: 최소한으로 시작하고, 정상적으로 종료하고, 갑작스러운 프로세스 종료를 허용하여 앱을 일회성으로 설계합니다. 컨테이너, 팟(Pod) 및 작업자 노드도 일회성이 되도록 앱을 적절하게 계획해야 합니다.
10. 개발-프로덕트 간 패리티: 개발 중인 앱과 프로덕션 중인 앱 간의 차이를 최소화하면서 앱에 대한 지속적 통합 및 지속적 배포 파이프라인을 설정하세요.
11. 로그: 로그를 이벤트 스트림으로 간주합니다. 외부 또는 호스트 환경은 로그 파일을 처리하고 라우팅합니다. 중요: Red Hat OpenShift on IBM Cloud에서 로그는 기본적으로 켜져 있지 않습니다. 사용으로 설정하려면 로그 전달 구성을 참조하십시오.
12. 관리자 프로세스: 일회성 관리자 스크립트를 앱과 함께 보관하고 Kubernetes 작업 개체로 실행하여 관리자 스크립트가 앱 자체와 동일한 환경에서 실행되도록 합니다. Kubernetes 클러스터에서 실행하려는 대규모 패키지의 오케스트레이션을 위해 다음과 같은 패키지 관리자를 사용하는 것을 고려해보십시오 Helm.

서버리스 앱은 어떻습니까?

IBM Cloud Code Engine 서비스를 통해 서버리스 앱 및 작업을 실행할 수 있습니다. Code Engine에서 사용자의 이미지를 빌드할 수도 있습니다.

앱이 이미 설치되어 있습니다. Red Hat OpenShift on IBM Cloud로 마이그레이션할 수 있는 방법은 무엇입니까?

앱을 컨테이너화하려면 다음과 같이 일반적인 단계를 수행할 수 있습니다.

1. 종속성을 분리하고, 프로세스를 별도의 서비스로 분리하고, 앱의 상태 저장성을 최대한 줄이기 위한 지침으로 Twelve-Factor 앱을 사용하세요.
2. 사용할 적합한 기본 이미지를 찾으십시오. Docker 허브에서 공개적으로 사용 가능한 이미지, 공개 IBM 이미지를 사용하거나 비공개 IBM Cloud Container Registry 에서 직접 이미지를 만들고 관리할 수 있습니다.
3. 앱 실행에 필수인 항목만 Docker 이미지에 추가하십시오.
4. 공통 앱 수정 시나리오를 검토하십시오.
5. 로컬 스토리지에 의존하는 대신 앱의 데이터를 백업하려면 지속적 스토리지 또는 클라우드 Database-as-a-service 솔루션을 사용해보십시오.
6. 시간 경과에 따라 앱 프로세스를 마이크로서비스로 리팩터링하십시오.

배치에 권한 있는 액세스를 제공하는 단계 예제

루트 권한으로 실행하는 앱이 있는 경우 Red Hat OpenShift 클러스터에 대해 설정되어 있는 보안 컨텍스트 제한조건에 대해 작업하도록 배치를 수정해야 합니다. 예를 들어, 서비스 계정으로 프로젝트를 설정하여 권한 있는 액세스를 제어한 다음, 이 서비스 계정을 사용하도록 배치를 수정할 수 있습니다.

시작하기 전에: Red Hat OpenShift 클러스터에 액세스하십시오.

1. 클러스터 관리자로서 프로젝트를 작성하십시오.

   oc adm new-project <project_name>
   

2. 작성된 후속 리소스가 프로젝트 네임스페이스에 있도록 프로젝트를 대상으로 지정하십시오.

   oc project <project_name>
   

3. 프로젝트의 서비스 계정을 작성하십시오.

   oc create serviceaccount <sa_name>
   

4. 권한 있는 보안 컨텍스트 제한조건을 프로젝트의 서비스 계정에 추가하십시오. privileged SCC에 있는 정책을 확인하려면 oc describe scc privileged를 실행하십시오. SCC에 대한 자세한 정보는 Red Hat OpenShift 문서를 참조하십시오.

   oc adm policy add-scc-to-user privileged -n <project_name> -z <sa_name>
   

5. 배치 구성 파일에서 권한 있는 서비스 계정을 참조하고 보안 컨텍스트를 권한 있음으로 설정하십시오.

   • spec.template.spec에 serviceAccount: <sa_name>을 추가하십시오.
   • spec.template.spec.containers에 securityContext: privileged: true을 추가하십시오.

   예

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: myapp_deployment
     labels:
       app: myapp
   spec:
     ...
     template:
       ...
       spec:
         serviceAccount: <sa_name>
         containers:
         - securityContext:
             privileged: true
         ...
   

6. 앱 구성 파일을 배치하십시오.

   oc apply -f <filepath/deployment.yaml>
   

7. 팟(Pod)이 실행 중 상태인지 확인하십시오. 팟(Pod)에 오류 상태가 표시되거나 오랫동안 한 상태로 고정되어 있는 경우, 팟(Pod)에 대해 설명하고 이벤트 섹션을 검토하여 배치 문제점 해결을 시작하십시오.

   oc get pods
   

내 앱을 컨테이너에 배치해야 한다고 생각했습니다. 팟(Pod)에 대한 이 항목은 무엇입니까?

파드는 Kubernetes 관리할 수 있는 가장 작은 배포 단위입니다. 컨테이너(또는 컨테이너의 그룹)을 팟(Pod)에 배치하고 팟(Pod) 구성 파일을 사용하여 컨테이너를 실행하고 리소스를 다른 팟(Pod)과 공유하는 방법을 알려줍니다. 파드에 넣은 모든 컨테이너는 공유 컨텍스트에서 실행되며, 이는 가상 또는 물리적 머신을 공유한다는 의미입니다.

컨테이너에 배치할 항목

애플리케이션의 컴포넌트에서와 같이 CPU 및 메모리와 같은 항목에 대해 완전히 다른 리소스 요구사항이 있는지 여부를 확인하십시오. 일부 컴포넌트가 최대 성능으로 실행될 수 있으며, 리소스를 다른 영역으로 전환함에 따라 발생하는 잠깐 동안의 성능 저하가 허용됩니까? 다른 컴포넌트가 고객 지향적이므로 성능을 유지하는 것이 중요합니까? 별도의 컨테이너로 분할하십시오. 동기화 상태로 함께 실행되도록 항상 동일한 팟(Pod)에 배치할 수 있습니다.

팟(pod)에 배치할 항목

앱의 컨테이너가 항상 동일한 팟(pod)에 있지 않아도 됩니다. 실제로, 데이터베이스 서비스와 같이 Stateful이고 스케일링하는 데 어려움이 있는 컴포넌트가 있는 경우 워크로드를 처리하도록 추가 리소스가 포함된 작업자 노드에서 스케줄할 수 있는 다른 팟(Pod)에 배치하십시오. 컨테이너가 다른 작업자 노드에서 실행되면 올바르게 작동하는 경우에는 여러 팟(Pod)을 사용하십시오. 동일한 머신에 있어야 하고 함께 스케일링되어야 하는 경우 컨테이너를 동일한 팟(Pod)으로 그룹화하십시오.

그렇다면 포드를 사용할 수 있다면 왜 이렇게 다양한 유형의 개체가 필요할까요?

팟(Pod) YAML 파일을 작성하는 것은 쉽습니다. 다음과 같이 몇 개의 행으로만 팟(Pod) YAML 파일을 작성할 수 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

그러나 사용자는 해당 지점에서의 중단을 원하지 않습니다. 팟(Pod)이 실행되는 노드가 작동 중지된 경우 팟(Pod)은 노드와 함께 작동 중지되고 다시 스케줄되지 않습니다. 대신 배포를 사용하여 파드 일정 변경, 복제본 세트 및 롤링 업데이트를 지원하세요. 기본 배치는 팟(Pod)만큼 쉽게 작성할 수 있습니다. 그러나 자체적으로 spec에서 컨테이너를 정의하는 대신 배치 replicas에서 template 및 spec를 지정합니다. 템플리트에는 다음과 같이 배치 내의 클러스터에 적합한 고유 spec이 있습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

동일한 모든 YAML 파일에서 팟(Pod) 반친화성 또는 리소스 한계와 같은 기능 추가를 계속할 수 있습니다.

배포에 추가할 수 있는 다양한 기능에 대한 자세한 설명은 앱 배포 YAML 파일 만들기를 참조하세요.

내 앱에 대해 어떤 유형의 Kubernetes 오브젝트를 작성할 수 있습니까?

앱 YAML 파일을 준비할 때는 앱의 가용성, 성능 및 보안을 향상시키기 위한 다양한 선택사항이 있습니다. 예를 들면, 단일 팟(Pod) 대신 Kubernetes 제어기 오브젝트를 사용하여 복제본 세트, 작업 또는 디먼 세트와 같은 워크로드를 관리할 수 있습니다. 포드 및 컨트롤러에 대한 자세한 내용은 Kubernetes 문서를 참조하세요. 팟(Pod)의 복제본 세트를 관리하는 배치는 앱에 대한 공통 유스 케이스입니다.

예를 들면, kind: Deployment 오브젝트를 사용하면 팟(Pod)의 가용성을 높일 수 있는 복제본 세트를 지정할 수 있으므로 이는 앱 팟(Pod)을 배치하는 데 있어서 좋은 선택사항입니다.

다음 표에는 다양한 Kubernetes 워크로드 오브젝트를 작성하는 이유가 설명되어 있습니다.

내 앱 구성에서 변수를 사용하도록 하려면 어떻게 해야 합니까? 이러한 변수를 YAML에 추가하려면 어떻게 하나요?

데이터를 YAML 파일에 하드코딩하는 대신 배포에 변수 정보를 추가하려면 Kubernetes ConfigMap 또는 Secret 객체를 사용하면 됩니다.

ConfigMap 또는 secret을 이용하려면 이를 팟(Pod)에 마운트해야 합니다. ConfigMap 또는 secret은 팟(Pod)이 실행되기 직전에 팟(Pod)과 결합됩니다. 배치 스펙 및 이미지는 여러 앱에 걸쳐 재사용할 수 있지만, 그 후에는 사용자 정의된 ConfigMap 및 secret을 스왑 아웃하십시오. 특히 secret은 로컬 노드에서 많은 스토리지를 차지할 수 있으므로 적절히 계획하십시오.

두 리소스는 모두 키-값 쌍을 정의하지만, 사용자는 둘을 서로 다른 상황에 사용합니다.

ConfigMap

배치에 지정된 워크로드에 대한, 만감하지 않은 구성 정보를 제공합니다. ConfigMap의 주된 용도에는 세 가지가 있습니다.

• 파일 시스템: 전체 파일 또는 변수 세트를 팟(pod)에 마운트할 수 있습니다. 값에 설정된 파일의 키 이름 컨텐츠에 따라 각 항목에 대해 하나의 파일이 작성됩니다.
• 환경 변수: 컨테이너 스펙의 환경 변수를 동적으로 설정하십시오.
• 명령줄 옵션: 컨테이너 사양에 사용되는 명령줄 옵션을 설정합니다.

시크릿

워크로드에 다음과 같은 민감한 정보를 제공합니다. 클러스터의 다른 사용자에게 시크릿에 대한 액세스 권한이 있을 수 있으므로, 시크릿 정보가 이러한 사용자와 공유될 수 있다는 점을 반드시 알고 있어야 합니다.

• PII(Personally Identifiable Information): 시크릿에 이메일 주소 또는 회사나 정부의 규제 준수에 필요한 기타 정보와 같은 민감한 정보를 저장하십시오.
• 인증 정보: 비밀번호, 키, 토큰과 같은 인증 정보를 시크릿에 입력하여 실수로 노출할 위험을 줄이십시오. 예를 들어, 클러스터에 서비스를 바인드하는 경우에는 인증 정보가 Secret에 저장됩니다.

secret을 더 안전하게 보호하려고 하십니까? 클러스터 관리자에게 클러스터에서 키 관리 서비스 제공자를 사용으로 설정하여 새 시크릿 및 기존 시크릿을 암호화하도록 요청하십시오.

내 앱에 올바른 리소스가 있는지 확인하려면 어떻게 해야 하나요?

앱 YAML 파일을 지정할 때 앱 구성에 Kubernetes 기능을 추가하여 앱이 올바른 리소스를 가져오는 데 도움을 줄 수 있습니다. 특히 YAML 파일에 정의된 각 컨테이너에 대한 리소스 제한 및 요청을 설정하세요.

추가로, 클러스터 관리자는 다음과 같이 앱 배치에 영향을 주는 리소스 제어를 설정할 수 있습니다.

• 리소스 할당량
• 팟(Pod) 우선순위

내 앱 구성에 기능을 추가하는 방법은 무엇입니까?

배치에 포함시킬 수 있는 항목에 대한 설명은 YAML 파일에 앱 요구사항 지정을 참조하십시오. 이 예제에는 다음 옵션이 포함되어 있습니다.

• 복제본 세트
• 레이블
• 친화성
• 이미지 정책
• 포트
• 리소스 요청 및 한계
• 활성 상태 및 준비 상태 프로브
• 포트에 앱 서비스를 노출하는 서비스입니다.
• Configmaps-컨테이너 환경 변수를 설정합니다.
• 시크릿: 컨테이너 환경 변수를 설정합니다.
• 스토리지를 위해 컨테이너에 마운트되는 영구 볼륨입니다.

내 앱에 Watson과 같은 IBM 서비스를 추가하는 방법은 무엇입니까?

앱에 서비스 추가를 참조하십시오.

내 앱의 가용성을 높이는 방법은 무엇입니까?

앱의 가용성을 높이려면 다음 옵션을 고려하십시오.

배치 및 복제본 세트를 사용하여 앱과 해당 종속 항목 배치

배치는 앱과 해당 종속 항목의 모든 컴포넌트를 선언하는 데 사용할 수 있는 Kubernetes 리소스입니다. 배치를 사용하면 모든 단계를 기록할 필요 없이 앱에 집중할 수 있습니다. 둘 이상의 팟(Pod)을 배치하는 경우, 팟(Pod)을 모니터하며 지정된 수의 팟(Pod)이 시작되고 실행되도록 보장하는 복제본 세트가 배치에 대해 자동으로 작성됩니다. 팟(Pod)이 중단되는 경우, 복제본 세트는 응답하지 않는 팟(Pod)을 새 팟(Pod)으로 대체합니다. 배치를 사용하여 앱에 대한 업데이트 전략(롤링 업데이트 중에 추가할 팟(Pod)의 수와 한 번에 사용 불가능 상태가 될 수 있는 팟(Pod)의 수 포함)을 정의할 수 있습니다. 롤링 업데이트를 수행할 때 배치는 개정이 작동 중인지 여부를 확인하며, 장애가 발견되면 롤아웃을 중지합니다. 배포를 사용하면 서로 다른 옵션으로 여러 개의 리비전을 동시에 배포할 수 있습니다. 예를 들면, 배치를 프로덕션으로 푸시하기로 결정하기 전에 먼저 이를 테스트할 수 있습니다. 배치를 사용하면 배치된 개정을 추적할 수 있습니다. 사용자는 이 히스토리를 사용하여 업데이트가 예상한 대로 작동하지 않는 경우 이전 버전으로 롤백할 수 있습니다.

앱의 워크로드를 위한 충분한 복제본과 두 개의 추가 복제본 포함

앱의 보다 높은 가용성과 장애에 대한 복원성을 더욱 높이려면, 예상된 워크로드를 처리할 수 있도록 최소량 이상의 추가 복제본을 포함할 것을 고려하십시오. 팟(Pod)이 충돌했으며 복제본 세트가 아직 충돌된 팟(Pod)을 복구하지 않은 경우에는 추가 복제본이 워크로드를 처리할 수 있습니다. 두 건의 장애가 동시에 발생하지 않도록 방지하려면, 두 개의 추가 복제본을 포함하십시오. 이 설정은 N + 2 패턴으로, 여기서 N은 수신 워크로드를 처리하기 위한 복제본의 수이며 + 2는 두 개의 추가 복제본입니다. 팟(Pod)은 클러스터에 충분한 공간이 있는 한 원하는 만큼 보유할 수 있습니다.

여러 노드 간에 팟(Pod) 전개(반친화성)

배치를 작성할 때 각 팟(Pod)을 동일한 작업자 노드에 배치할 수 있습니다. 이를 선호도 또는 코로케이션이라고 합니다. 작업자 노드 장애로부터 앱을 보호하기 위해, 표준 클러스터에 podAntiAffinity 옵션을 사용하여 여러 작업자 노드에 팟(Pod)이 분산되도록 배치를 구성할 수 있습니다. 팟(Pod) 반친화성에는 선호 및 필수의 두 가지 유형이 있습니다. 자세한 내용은 노드에 파드 할당에 대한 Kubernetes 문서를 참조하세요.

앱 배치에서의 친화성에 대한 예는 앱 배치 YAML 파일 작성을 참조하십시오.

여러 구역 또는 지역 간에 팟(Pod) 분배

구역 장애에서 앱을 보호하기 위해, 별도의 구역에서 다중 클러스터를 작성하거나 다중 구역 클러스터의 작업자 풀에 구역을 추가할 수 있습니다. 다중 구역 클러스터는 특정 클래식 또는 VPC 다중 구역(예: 댈러스)에서만 사용 가능합니다. 별도의 구역에서 다중 클러스터를 작성하는 경우에는 글로벌 로드 밸런서를 설정해야 합니다. 복제본 세트를 사용하고 팟(Pod) 반친화성을 지정하는 경우, Kubernetes는 노드 간에 앱 팟(Pod)을 전개합니다. 노드가 다중 구역에 있으면 팟(Pod)이 구역 간에 전개되며 앱의 가용성이 증가됩니다. 하나의 구역에서만 실행하도록 앱을 제한하려는 경우에는 팟(Pod) 친화성을 구성하거나 하나의 구역에서 작업자 풀을 작성하고 해당 레이블을 지정할 수 있습니다.

멀티존 클러스터 배포에서 앱 포드가 노드에 고르게 분산되어 있나요?

팟(Pod)은 구역 간에는 균등하게 분배되어 있지만, 노드 간에는 항상 그렇지 않습니다. 예를 들어, 세 개의 구역 각각에 하나의 노드가 있는 클러스터가 있고 팟(Pod)이 여섯 개인 복제본 세트를 배치하는 경우에는 각 노드가 두 개의 팟(Pod)을 갖습니다. 그러나 세 개의 구역 각각에 두 개의 노드가 있는 클러스터가 있고 팟(Pod)이 여섯 개인 복제본 세트를 배치하는 경우에는 각 구역이 두 개의 팟(Pod)을 스케줄하며, 노드당 하나의 팟(Pod)을 스케줄할 수도 있고 스케줄하지 않을 수도 있습니다. 스케줄을 더 잘 제어하려면 포드 선호도를 설정할 수 있습니다.

하나의 존이 다운되면 다른 존의 나머지 노드에 어떻게 파드가 재조정되나요?

이는 배치에서 사용한 스케줄링 정책에 따라 다릅니다. 노드별 파드 선호도를 포함시킨 경우, 파드는 스케줄이 변경되지 않습니다. 그렇지 않은 경우에는 팟(Pod)이 기타 구역의 사용 가능한 작업자 노드에서 작성되지만, 이의 밸런스가 유지되지 않을 수 있습니다. 예를 들면 두 개의 팟(Pod)이 두 개의 사용 가능한 노드에 분배되거나, 둘 모두 가용 용량이 있는 하나의 노드에 스케줄될 수 있습니다. 이와 유사하게, 사용 불가능한 구역이 리턴되면 팟(Pod)이 자동으로 삭제되지 않으며 노드 간에 리밸런싱됩니다. 존이 백업된 후 존 전체에서 파드의 밸런스를 재조정하려면 Kubernetes 스케줄러 를 구성한다. 멀티존 클러스터에서는 영역별 작업자 노드 용량을 50%로 유지하여 영역 장애로부터 클러스터를 보호하기에 충분한 용량이 남도록 하세요.

앱을 여러 지역에 배포하려면 어떻게 해야 하나요?

지역 장애로부터 앱을 보호하려면 다른 지역에 두 번째 클러스터를 생성하고, 글로벌 로드 밸런서를 설정하여 클러스터를 연결하고, 배포 YAML을 사용하여 앱에 대한 포드 안티 선호도가 있는 중복 복제본 세트를 배포하세요.

앱에 영구 저장 공간이 필요한 경우 어떻게 하나요?

IBM Cloudant 또는 IBM Cloud Object Storage 등의 클라우드 서비스를 사용하십시오.

내 앱을 스케일링하는 방법은 무엇입니까?

워크로드 사용량에 따라 동적으로 앱을 추가하고 제거하려는 경우 수평 팟(Pod) Auto-Scaling을 사용으로 설정하기 위한 단계에 대한 앱 스케일링을 참조하십시오.

내 배치를 좀 더 쉽게 업데이트하고 관리할 수 있도록 구성하는 방법은 무엇입니까?

이제 사용자는 배치에 포함될 항목에 대해 잘 알게 되었으며, 다양한 YAML 파일을 어떻게 관리할 것인지 궁금할 수 있습니다. Kubernetes 환경에서 작성하는 오브젝트 또한 해당됩니다!

다음 팁은 배치 YAML 파일을 구성하는 데 도움을 줄 수 있습니다.

• Git과 같은 버전 제어 시스템을 사용하십시오.
• 단일 YAML 파일 내에서 밀접하게 관련된 Kubernetes 오브젝트를 그룹화하십시오. 예를 들어, deployment를 작성하는 경우 service 파일을 YAML에 추가할 수도 있습니다. 다음 예제에서와 같이 오브젝트를 ---로 구분하십시오.

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  ...
  ---
  apiVersion: v1
  kind: Service
  metadata:
  ...
  

• 단일 파일만이 아닌 oc apply -f 명령을 사용하여 전체 디렉토리에 적용할 수 있습니다.
• Kubernetes 리소스 YAML 구성을 작성하고, 사용자 정의하고, 재사용하는 데 도움을 받기 위해 사용할 수 있는 kustomize 프로젝트를 사용해 보십시오.

YAML 파일 내에서 배치를 관리하는 메타데이터로서 레이블 또는 어노테이션을 사용할 수 있습니다.

Labels

레이블은 key:value 쌍으로, 파드 및 배포와 같은 Kubernetes 오브젝트에 첨부할 수 있습니다. 사용자가 원하는 대로 지정할 수 있으며 레이블 정보를 기반으로 하여 오브젝트를 선택하는 데 유용합니다. 레이블은 오브젝트를 그룹화하기 위한 기반을 제공합니다. 레이블의 아이디어는 다음 예제를 참조하십시오.

• app: nginx
• version: v1
• env: dev

어노테이션

주석도 key:value 쌍이라는 점에서 레이블과 유사합니다. 오브젝트 생성 위치, 오브젝트 사용 방법, 연관된 추적 저장소에 대한 포인터 또는 오브젝트에 대한 정책과 관련된 추가 정보 보유와 같이 도구 또는 라이브러리로 활용될 수 있는 비식별 정보에 더욱 적합합니다. 어노테이션을 기반으로 한 오브젝트를 선택하지 않습니다.

사용할 수 있는 앱 업데이트 전략은 무엇입니까?

앱을 업데이트하려면 다음과 같은 다양한 전략 중에서 선택할 수 있습니다. 더욱 복잡한 Canary 배치를 진행하기 전에 롤링 배치 또는 즉각적인 전환을 시작할 수 있습니다.

롤링 배치

Kubernetes 원시 기능을 사용하여 v2 배치를 작성하고 점진적으로 이전 v1 배치를 대체할 수 있습니다. 이 접근 방식을 사용하려면 앱이 이전 버전과 호환되어야 v2 앱 버전을 제공받는 사용자가 변경 사항을 경험하지 않습니다. 자세한 정보는 앱 업데이트를 위한 롤링 배치 관리를 참조하십시오.

즉각적인 전환

즉각적인 전환은 Blue-Green 배치라고도 하며, 두 개의 버전이 동시에 실행되도록 두 배 크기의 컴퓨팅 리소스가 필요합니다. 이 접근 방식을 사용하면 거의 실시간으로 사용자를 최신 버전으로 전환할 수 있습니다. 서비스 라벨 선택기(예: version: green 및 version: blue)를 사용하여 요청이 올바른 앱 버전으로 전송되는지 확인하세요. 새 version: green 배치를 작성할 수 있습니다. 준비가 될 때까지 기다린 후 version: blue 배치를 삭제하십시오. 또는 롤링 업데이트를 수행할 수 있지만 maxUnavailable 매개변수를 0%로 설정하고 maxSurge 매개변수를 100%로 설정하십시오.

Canary 또는 A/B 배치

더욱 복잡한 업데이트 전략인 Canary 배치는 5%와 같은 사용자의 백분율을 선택하여 새 앱 버전으로 전송하는 경우에 수행됩니다. 새 앱 버전에서 수행되는 방식을 알아보기 위해 로깅 및 모니터링 도구에서 메트릭을 수집하고, A/B 테스트를 수행한 후 더 많은 사용자에게 업데이트를 롤아웃합니다. 모든 배치에서와 같이 앱(예: version: stable 및 version: canary)에 레이블을 지정하는 것이 중요합니다.

내 배치를 자동화하는 방법은 무엇입니까?

다중 클러스터, 공용 및 사설 환경 또는 클라우드 제공자에서도 앱을 실행할 경우 이 환경에서 배치 전략 작업을 수행할 수 있는 방법을 궁금해할 수 있습니다. IBM Cloud 및 기타 오픈 소스 도구를 사용하여 배치 자동화를 지원하도록 애플리케이션을 패키징할 수 있습니다.

지속적 통합 및 지속적 딜리버리(CI/CD) 파이프라인 설정

Git과 같은 소스 제어 관리 시스템에서 구성된 앱 구성 파일을 사용하여 여러 환경에 test 및 prod와 같은 코드를 테스트하고 배치하도록 파이프라인을 빌드할 수 있습니다. 클러스터 관리자와 작업하여 지속적 통합 및 딜리버리를 설정하십시오.

앱 구성 파일 패키지

Kustomize 또는 Helm과 같은 도구를 사용하여 앱을 패키지하십시오.

• kustomize 프로젝트를 통해 Kubernetes 리소스 YAML 구성을 작성하고, 사용자 정의하고, 재사용할 수 있습니다.
• 패키지 관리자를 사용하면 Helm Kubernetes 패키지 관리자를 사용하면 앱에 필요한 모든 Kubernetes 리소스를 Helm 차트에 지정할 수 있습니다. 그런 다음 클러스터에서 Helm을 사용하여 YAML 구성 파일을 작성하고 이 파일을 배치할 수 있습니다. 블록 스토리지 플러그인 등을 사용해 IBM Cloud 에서 제공하는 Helm 차트를 통합해 클러스터의 기능을 확장할 수도 있습니다.

YAML 파일 템플리트를 작성하시겠습니까? 어떤 사람들은 Helm 를 사용하거나 다음과 같은 다른 커뮤니티 도구를 사용해 볼 수도 있습니다 ytt.

내 서비스가 올바른 배포에 연결되어 있고 바로 사용할 준비가 되었는지 확인하려면 어떻게 해야 하나요?

대부분의 서비스의 경우 해당 레이블로 앱을 실행하는 팟(Pod)에 적용되도록 선택기를 서비스 .yaml 파일에 추가하십시오. 앱이 처음 시작될 때 요청을 즉시 처리하지 않으려는 경우가 많습니다. 트래픽이 준비 상태로 간주되는 팟(Pod)으로만 전송되도록 준비 상태 프로브를 배치에 추가하십시오. 레이블을 사용하고 준비 상태 프로브를 설정하는 서비스 배포의 예는 이 NGINX YAML을 확인하세요.

서비스가 레이블을 사용하지 않기를 원하는 경우도 있습니다. 예를 들어, 외부 데이터베이스가 있거나 서비스를 클러스터 내 다른 네임스페이스의 또 다른 서비스로 지정하려고 할 수 있습니다. 해당 경우 엔드포인트 오브젝트를 수동으로 추가하고 이를 서비스에 연결해야 합니다.

인터넷에 내 서비스를 노출할 수 있는 방법은 무엇입니까?

외부 네트워킹을 위한 세 가지 유형의 서비스 즉, NodePort, LoadBalancer 및 Ingress를 작성할 수 있습니다.

클러스터 유형에 따라 여러 선택사항이 있습니다. 자세한 정보는 네트워킹 서비스 계획을 참조하십시오.

• 표준 클러스터: NodePort, 로드 밸런서 또는 Ingress 서비스를 사용하여 앱을 노출할 수 있습니다.
• Calico를 사용하여 사설로 설정된 클러스터: NodePort, 로드 밸런서 또는 Ingress 서비스를 사용하여 앱을 노출할 수 있습니다. 또한 Calico preDNAT 네트워크 정책을 사용하여 공용 노드 포트를 차단해야 합니다.

클러스터에 필요한 Service 오브젝트의 수를 계획할 때 Kubernetes가 네트워킹 및 포트 전달 규칙을 처리하는 데 iptables를 사용하는 점에 유의하십시오. 클러스터에서 많은 서비스(예: 5000개)를 실행하는 경우 성능에 영향을 줄 수 있습니다.

내 앱 배치에 대한 액세스 권한을 갖는 사용자를 제어하는 방법은 무엇입니까?

계정 및 클러스터 관리자는 다양한 레벨(클러스터, Red Hat OpenShift 프로젝트, 팟(Pod), 컨테이너)에서의 액세스 권한을 제어할 수 있습니다.

IBM Cloud IAM을 사용하면 클러스터-인스턴스 레벨에서 개별 사용자, 그룹 또는 서비스 계정에 권한을 지정할 수 있습니다. 사용자를 클러스터 내 특정 네임스페이스로 제한하여 클러스터 액세스 권한을 더 자세한 범위로 지정할 수 있습니다. 자세한 정보는 클러스터 액세스 권한 지정을 참조하십시오.

팟(Pod) 레벨에서 액세스 권한을 제어하려는 경우에는 보안 컨텍스트 제한조건(SCC)을 구성할 수 있습니다.

앱 배치 YAML에는 팟(Pod) 또는 컨테이너에 대한 보안 컨텍스트를 설정할 수 있습니다. 자세한 내용은 Kubernetes 문서를 참조하세요.

앱을 배치한 후 해당 상태를 모니터링하는 방법은 무엇입니까?

클러스터에 대한 IBM Cloud 로깅 및 모니터링을 설정할 수 있습니다.