클라우드/DevOps

[Red Hat OpenShift] 개념, ROSA Hands-on : cluster 구성 및 autoscale, labeling

dayeonsheep 2024. 3. 19. 02:09

Main reference 

 

1) Day 56

< Red Hat Openshift 개념 >

 
k8s 제공하는 공급업체 : Red hat openshift , Google Anthos, EKS, Azure k8s survice, VMware tanzu 등 
 
그 중에서 Red hat openshift 
 
1. 그게 뭔가?
쿠버네티스 기반 으로한 더 많은 기능을 제공하는 상위 수준 컨테이너 오케스트레이션 플랫폼
(근데 왜 k8s보다 많이 안쓰나? --> 얘는 상용이라 돈 많이 듬)

 
2. 어떤 기능 제공하나?
https://www.redhat.com/en/resources/openshift-container-platform-datasheet

Red Hat OpenShift Container Platform

This datasheet provides product details about Red Hat OpenShift Container Platform—open to any application, team, or infrastructure.

www.redhat.com

 

  • 사전 빌드된 컨테이너 이미지 및 컨테이너 런타임 환경
  • 통합된 오픈 소스 플랫폼 및 컨테이너 런타임 환경
  • 데이터베이스, 메시징, 스토리지 등 광범위한 서비스에 액세스
  • 맞춤형 애플리케이션 배포
  • 웹 기반 사용자 인터페이스, 명령줄 도구 및 API
  • 모니터링 및 로깅 기능
  • 보안 및 리소스 격리
  • 자동화된 빌드 및 배포 파이프라인
  • 지속적인 통합 및 지속적 전달(CI/CD) 기능
  • 등등... 

 
3. 어디에 배포할 수 있나?

  • Cloud Service Editions - 레드햇이 관리 : AWS(rosa), Azure, IBM cloud, Red hat dedicated 
  • Self-Managed Editions - 사용자가 관리 :AWS, GCP, Azure, IBM Cloud, VMware Cloud on AWS 등등... 

 
+ k8s와 레드햇 오픈시프트의 차이

더보기

쿠버네티스 = 컨테이너 오케스트레이션 도구
레드햇 오픈시프트 = 쿠버네티스 기반 컨테이너 오케스트레이션 플랫폼 인데, 

1. **추가 기능 및 도구**: 레드햇 오픈시프트는 쿠버네티스의 기본 기능을 확장하여 추가 기능 및 도구를 제공합니다. 예를 들어, 오픈시프트는 CI/CD, GitOps, 모니터링, 로깅 등의 기능을 내장하고 있습니다. 이는 개발자 및 운영팀이 애플리케이션을 보다 쉽게 관리하고 확장할 수 있도록 도와줍니다.

2. **상용 지원**: 레드햇 오픈시프트는 상용 지원과 서비스를 제공하는 레드햇의 제품입니다. 이는 기업 환경에서 안정성과 신뢰성을 보장하기 위해 중요합니다. 쿠버네티스는 오픈소스 프로젝트이며, 상용 지원은 제공되지 않습니다. 따라서 기업이 쿠버네티스를 사용할 때 추가적인 지원이 필요할 수 있습니다.

3. **사용자 인터페이스**: 레드햇 오픈시프트는 사용자 친화적인 웹 기반 관리 콘솔을 제공하여 클러스터 관리 및 애플리케이션 배포를 쉽게 할 수 있도록 도와줍니다. 쿠버네티스는 주로 명령줄 인터페이스를 사용하여 관리되지만, 몇 가지 UI 도구도 있습니다.

4. **인프라스트럭처 지원**: 레드햇 오픈시프트는 다양한 클라우드 환경 및 온프레미스 인프라스트럭처를 지원합니다. 쿠버네티스는 다양한 환경에서 실행될 수 있지만, 몇몇 클라우드 플랫폼에 특화된 기능도 있습니다.

쿠버네티스는 컨테이너 오케스트레이션을 위한 오픈소스 플랫폼이며, 
레드햇 오픈시프트는 쿠버네티스를 기반으로 한 상위 수준의 컨테이너 오케스트레이션 플랫폼으로, 추가 기능 및 상용 지원 등을 제공하여 기업 환경에서의 사용을 용이하게 합니다.

 
 


 

1) Day 57

< Red Hat Openshift - Architecture >

 
1. 기본 운영체제 : CoreOS
 
2. 아키텍처
 
- 쿠버네티스 기반 플랫폼 아키텍처

- 컨트롤 플레인 아키텍처 

 

  • 클러스터 생성 및 관리 단순화
  • 애플리케이션 개발자가 애플리케이션을 모니터링하고 확장하는 기능과 같은 워크로드 수명주기 관리가 포함된 애플리케이션을 생성 및 배포할 수 있는 도구가 내장

 
- Operator? 
 
https://operatorhub.io/what-is-an-operator

OperatorHub.io | The registry for Kubernetes Operators

operatorhub.io

 

  • 기본적으로 통합하여 Kubernetes 클러스터 내에서 실행되는 소프트웨어에서 일반적인 1일차(설치, 구성 등) 및 2일차(재구성, 업데이트, 백업, 장애 조치, 복원 등) 활동을 구현하고 자동화
  • Kubernetes 개념과 API를 사용
  • 이것을 Kubernetes 네이티브 애플리케이션이라고 부름
  • Operators를 사용하면 애플리케이션을 Pod, 배포, 서비스 또는 ConfigMap과 같은 기본 요소의 컬렉션으로 처리하는 대신 애플리케이션에 적합한 knob만 노출하는 단일 객체로 처리할 수 있음

 


 

1) Day 58 

< Red Hat Openshift 설치하기 >

 
FQDN - vCenter가 사용할 DNS 주소 
 
90DevOps 리드미대로 하려고 했으나, red hat openshift를 로컬에 설치하기 이전에 VMware 설정에서 애를 먹었다

출처:&amp;nbsp;https://blog.naver.com/ki630808/221691955388

 
참고했던 vCenter와 VMware의 구성... 하지만 실패...
 

 


 
그래서 90devops 레퍼런스 말고!
레드햇에서 제공해주는 핸즈온을 따라가보기로 했다(스터디 팀장님이 대체 핸즈온 가이드 찾아주심 완전 최고)
 

< 2) ROSA (Red Hat OpenShift Service on AWS) Hands-On >

 

1. Explore rosa environment

이미 로사가 설치되어 있는 핸즈온 가이드를 한 번 따라봅시다
rosa list clusters와 decribe 명령어로 상세 정보를 확인할 수 있음
 

API URL이랑 OpenShift Console URL 로도 접속가능

 

2. Rosa cluster upgrade 

  • ROSA(Red Hat OpenShift Service on AWS)는 완전관리형 클러스터 업그레이드를 제공함
  • ROSA SRE(사이트 안정성 엔지니어링)팀은 모든 ROSA 클러스터 업그레이드를 모니터링하고 관리
  • 고객은 업그레이드 전, 업그레이드 도중, 업그레이드 후에 SRE 팀으로부터 상태 이메일을 받음. 이러한 업데이트는 OCM(OpenShift Cluster Manager) 또는 ROSA CLI에서 업그레이드를 예약할 수 있음.

 

ROSA 업그레이드 중에는 한 번에 하나의 노드가 업그레이드

(이는 고가용성 및 내결함성 방식으로 배포된 경우 업데이트 중에 고객 애플리케이션이 영향을 받지 않도록 하기 위해)

 

<ROSA 클러스터를 업그레이드하는 방법>

1. OpenShift Cluster Manager 사용

2. CLI를 사용 

이 실습 환경에서는 OpenShift Cluster Manager에 액세스할 수 없으므로 rosaCLI를 사용해보자~

 

-> 버전 확인하는 명령어

 

-> ROSA 업그레이드에 사용 가능한 버전을 나열

 

-> oc adm upgrade해주기

export CLUSTER_VERSION="4.14.15"  이런식으로 버전 지정도 가능함 

 

 

 

실제로 클러스터를 업그레이드하면 랩 환경이 중단될 수 있어서 예약 기능도 있음

 

export UPGRADE_DATE=$(date -d "+24 hours" '+%Y-%m-%d')

export UPGRADE_TIME=$(date '+%H:%M')

echo Date: $UPGRADE_DATE, Time: $UPGRADE_TIME

 

이 샘플은 24시간 후의 날짜와 시간을 가져와서 upgrade time을 지정해준다~

  •  + OpenShift 업그레이드 그래프 도구로 업그레이드 확인할 수도 있다~

 

3. Managing worker nodes

ROSA 클러스터를 배포할 때 작업자 노드의 다양한 측면을 구성할 수 있음

if 작업자 노드가 이미 생성된 후 변경해야 하면?

노드 수 확장, 인스턴스 유형 변경, label 또는 taints 추가 등

--> 대부분은 머신 풀을 사용하여 수행됨

[ 머신 풀 ]

- 특정 시간에 지정된 수의 머신 복제본이 실행되도록 보장

- 클러스터의 작업자 노드를 구성하는 머신 종류에 대한 "템플릿" 정도

  • 확장성 - ROSA 머신 풀은 클러스터의 수평적 확장을 지원
  • 고가용성 - ROSA 머신 풀은 다양한 가용성 영역에 걸쳐 3개의 작업자 복제본 생성을 지원
  • 인프라 다양성 - ROSA 머신 풀을 사용하면 다양한 인스턴스 유형의 작업자 노드를 프로비저닝할 수 있음
  • Cluster Autoscaler와의 통합
    • ROSA Machine Pool은 현재 수요에 따라 작업자 노드 수를 자동으로 조정하는 Cluster Autoscaler 기능과 원활하게 통합됨
    • 이러한 통합은 필요에 따라 클러스터를 확장 또는 축소하고 비용과 성능을 최적화하여 효율적인 리소스 활용을 보장함

 

우선~ cluster리스트와 machinepool list를 확인하고

 

scale up our MachinePool from two to three machines 해보기 ↓

rosa update machinepool -c rosa-$GUID --replicas 3 workers

 

그런다음에

watch -n 10 oc get nodes

 

확인해보면

10초마다 어떻게 변경되는지 확인할 수 있음.

중간에 확인해보면 2개에서 3개로 변경된 걸 확인 가능

(3/3이 아닌 이유는 생성되는 시간을 다 안기다리고 캡쳐해서 그렇다)

그리고 다시 scaling down 을 해주려면

rosa update machinepool -c rosa-$GUID --replicas 2 workers

 이렇게 해주면 다시 2/2로 줄어든 걸 확인 가능

 

 

4. Autoscale rosa cluster

  • ROSA Cluster Autoscaler는 현재 워크로드 및 리소스 요구 사항에 따라 ROSA 클러스터의 크기를 자동으로 조정하는 데 도움이 되는 기능 
  • Cluster Autoscaler는 ROSA 클러스터의 자동 및 지능적 확장을 제공하여 효율적인 리소스 활용, 향상된 애플리케이션 성능, 고가용성 및 단순화된 클러스터 관리를 제공
  • 워크로드 수요에 따라 클러스터 크기를 동적으로 조정함으로써 조직이 인프라 비용을 최적화하는 동시에 최적의 애플리케이션 성능과 확장성을 보장하는 데 도움이 됨
  • Cluster Autoscaler는 사용자가 지정한 제한을 초과하여 클러스터 리소스를 늘리지 않음
출처: Red Hat Openshift

 
 
4.1. Enable Autoscaling on the Default MachinePool
 
- 클러스터에서 머신 풀 ID를 식별하기 & 머신 풀에서 자동 크기 조정을 활성화하기(enable-autoscaling)

autoscaling 추가하려는 MachinePool의 ID는 workers
 
 
네임스페이스(OpenShift에서는 프로젝트라고도 함)를 생성

나는 autoscale-ex 네임스페이스가 이미 있어서 autoscale-ex2로 만들어줌
 
 
4.2. Test the Cluster Autoscaler

- 클러스터의 리소스를 소진하고 더 많은 작업자 노드를 확장하게 하는 작업을 배포하기

이렇게 하면 maxsclae이 생성되었고
 
pod이 생성되고 있는 걸 확인 가능

 
그리고 클러스터의 노드 수를 확인해보기
4개의 노드(머신 풀 자동 크기 조정을 위해 구성한 최대값)가 나타날 때까지 이 명령을 반복해보자.
(autoscaler 를 4개의 worker nodes로 제한해 놓았음)
새 노드를 사용할 수 있으려면 몇 분(약 5분) 정도 걸린다고 함.

점차 늘어나는 걸 확인 가능
 
노드를 사용할 수 있게 되면 명령을 다시 실행하여 작업에 대한 Pod를 표시해보기

이제 더 많은 Pod가 실행되고 있는 것을 확인할 수 있음
4개의 작업자 노드라도 노드를 처리하기에 충분하지 않을 수 있으므로 일부 Pod가 보류 중 상태로 계속 표시되는 경우:
캡쳐화면엔 STATUS에 전부 completed인데 ContainerCreating, Pending으로 표시될 수 있음
 
 
4.2.1.Turn off autoscaling

--enable-autoscaling=false 
해서 autoscaling 끄기

그런다음 get nodes 해보면 SchedulingDisabled로 꺼지고 있는 걸 확인할 수 있음
 
 

5. Labeling Worker Nodes

  • Label은 애플리케이션이 실행될 노드를 선택하는 유용한 방법
  • 이러한 노드는 이 워크숍의 이전 섹션에서 작업한 MachineSet에 의해 정의된 머신에 의해 생성됨
  • 레이블 사용 사례의 예: 특정 노드 유형에서만 메모리 집약적인 애플리케이션을 실행하는 것

노드에 레이블을 직접 추가할 수 있지만, 노드가 다시 생성되어 레이블이 사라질 수 있으므로 권장되지 않음

>> 따라서 머신 풀 자체에 레이블을 지정해야 함

 

머신 풀 자체에 레이블 지정하는 실습

  • Machine Pools에 labels 추가하기
  • 특정 labels로 nodes위에 application 배포하기

 

5.1. cluster위에 machine pool을 업데이트해주기 

[rosa@bastion ~]$ rosa edit machinepool -c rosa-$GUID --labels tier=frontend workers
I: Updated machine pool 'workers' on hosted cluster 'rosa-2k4ts'

 
 
5.2. 노드 위에 수동으로 레이블을 지정해주기

[rosa@bastion ~]$ oc label nodes $(oc get nodes|grep -v NAME|cut -d' ' -f1) tier=frontend
node/ip-10-0-0-155.us-east-2.compute.internal not labeled
node/ip-10-0-0-242.us-east-2.compute.internal not labeled

 
 
5.3. 노드에 레이블이 올바르게 지정되었는지 확인

[rosa@bastion ~]$ oc get nodes --selector='tier=frontend' -o name
node/ip-10-0-0-155.us-east-2.compute.internal
node/ip-10-0-0-242.us-east-2.compute.internal

 
 
5.4. 레이블이 지정된 노드에 앱 배포하기 
 노드에 레이블을 잘 지정했으므로 nodeSelector를 사용해서 앱이 레이블이 지정된 노드에만 강제로 적용되도록 하기
 
5.4.1. 애플리케이션을 위한 프로젝트(또는 네임스페이스) 생성

[rosa@bastion ~]$ oc new-project nodeselector-ex2
Now using project "nodeselector-ex2" on server "https://api.rosa-2k4ts.l68x.p3.openshiftapps.com:443".

You can add applications to this project with the 'new-app' command. For example, try:

    oc new-app rails-postgresql-example

to build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application:

    kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.43 -- /agnhost serve-hostname

nodeselector-ex2라는 네임스페이스를 생성
 
5.4.2. 레이블이 지정된 노드를 대상으로 하는 애플리케이션 및 관련 리소스를 배포

[rosa@bastion ~]$ cat << EOF | oc apply -f -
---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nodeselector-app
  namespace: nodeselector-ex2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nodeselector-app
  template:
    metadata:
      labels:
        app: nodeselector-app
    spec:
      nodeSelector:
        tier: frontend
      containers:
      - name: hello-openshift
        image: "docker.io/openshift/hello-openshift"
        ports:
        - containerPort: 8080
          protocol: TCP
        - containerPort: 8888
          protocol: TCP
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
EOF
deployment.apps/nodeselector-app created

deployment.apps/nodeselector-app created 된 것을 확인 가능~
 
5.4.3. 애플리케이션이 레이블이 지정된 노드 중 하나에 배포되었는지 검증

[rosa@bastion ~]$ oc -n nodeselector-ex get pod -l app=nodeselector-app -o json \
  | jq -r .items[0].spec.nodeName
ip-10-0-0-242.us-east-2.compute.internal

 
 
5.4.4. 노드 이름을 다시 확인하여 위의 출력과 비교하여 노드 선택기가 Pod를 올바른 노드에 배치했는지 확인

[rosa@bastion ~]$ oc get nodes --selector='tier=frontend' -o name
node/ip-10-0-0-155.us-east-2.compute.internal
node/ip-10-0-0-242.us-east-2.compute.internal

 
 
5.4.5. oc expose command로 service 만들기

[rosa@bastion ~]$ oc expose deployment nodeselector-app
service/nodeselector-app exposed

잘 exposed 된 걸 확인 가능
 
 
5.4.6. route로 만들고 새 service expose 한 다음에 URL fetch하기

[rosa@bastion ~]$ oc create route edge --service=nodeselector-app  --insecure-policy=Redirect
route.route.openshift.io/nodeselector-app created

[rosa@bastion ~]$ echo "https://$(oc get routes/nodeselector-app -o json | jq -r '.spec.host')"
https://nodeselector-app-nodeselector-ex2.apps.rosa.rosa-2k4ts.l68x.p3.openshiftapps.com

 
그런다음 접속해보면

짜잔 배포가 잘 되었다. 
 
+ nodeSelector 알고가기

  • Kubernetes에서 Pod가 실행될 노드를 지정하는 데 사용되는 옵션
  • Red Hat OpenShift Service on AWS (ROSA)에서도 동일하게 사용됨
    일반적으로 "nodeSelector"는 Pod의 스케줄링을 특정 노드에 제한하거나 특정 노드에만 Pod를 스케줄링하기 위해 사용
  • 특정한 요구 사항을 충족하는 노드에만 특정한 Pod를 배치할 수 있음

노드에 파드 할당하기

특정한 노드(들) 집합에서만 동작하거나 특정한 노드 집합에서 동작하는 것을 선호하도록 파드를 제한할 수 있다. 이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두 레이

kubernetes.io

 

Kubernetes Pod 배치전략,  NodeSelector에 대해 이해하고 실습해보기

- minikube로 멀티노드 클러스터 구성을 이해하고 실습한다. - NodeSelector에 대해 이해하고 실습한다.

velog.io