Main reference
- 1) https://github.com/MichaelCade/90DaysOfDevOps/tree/main/2023
- 2) https://console.redhat.com/openshift/overview/rosa/hands-on
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 설정에서 애를 먹었다

참고했던 vCenter와 VMware의 구성... 하지만 실패...
- VMware vSphere? : https://docs.vmware.com/kr/VMware-vSphere/index.html
- vCenter server appliance 설치: https://blog.naver.com/PostView.naver?blogId=tjrwlstls92&logNo=221414293485&redirect=Dlog&widgetTypeCall=true&directAccess=false
- VSCA 설치 : https://ma-you-ing.tistory.com/12
- NCP 이용해서 RedhatOpenshift설치하기 : https://youtu.be/9aRlTF15N0E?si=gpss1Ay5JDALgN0O
- 오픈 시프트랑 쿠버네티스 간단한 설치 레퍼런스 : https://blog.naver.com/zilly1/222068007470
- OCP CLI 접근 : https://hs-note.tistory.com/8
- mac m1에 로컬설치하기 : https://blogbypuneeth.medium.com/install-redhat-openshift-local-on-mac-m1-c44bf4639692
그래서 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는 사용자가 지정한 제한을 초과하여 클러스터 리소스를 늘리지 않음

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
'클라우드 > DevOps' 카테고리의 다른 글
[90DayOfDevOps] Day 28~31 - Runtime Defence & Monitoring (2) | 2024.03.26 |
---|---|
[IaC] Terraform (0) | 2024.03.19 |
[90DaysOfDevOps] Day 53 - Kubernetes (0) | 2024.03.12 |
[90DaysOfDevOps] Day 49~52 - Kubernetes (1) | 2024.03.12 |
[90DaysOfDevOps] Day 46~48 - Container (Docker) (0) | 2024.03.10 |