반응형

 


 

 

Rook를 이용하여 Ceph 설치한 날짜: 2024년 8월 7일
Rook version: 1.10.10
Ceph version: 17.2.5(quincy) and 15.2.17 (octopus)      ## 이 두 버전 모두 잘 동작했다.

 

지난 2년 동안 NFS server를 이용하여 Kubernetes PV(Persistent Volume)의 Storage로 사용했었는데, 별로 좋지 않음을 경험하고는 Ceph를 사용해야겠다는 결단이 생겼다.

Ceph 설치가 만만치 않은 작업이지 않을까 걱정했는데, 괜한 걱정이었다.

Rook operator official document의 설명을 따라서 설치하니까 30분 만에 Ceph cluster가 뚝딱하고 만들어졌다.

Test용 Example App까지 Rook operator에 포함되어 있어서 Test까지 다 포함해서 1시간이 채 안 걸렸다.

 

일단, 아래 공식 문서인 Rook Ceph document를 읽고 따라하면 일사천리로 설치와 테스트가 모두 끝난다.

 

 

Quickstart - Rook Ceph Documentation

Quickstart Welcome to Rook! We hope you have a great experience installing the Rook cloud-native storage orchestrator platform to enable highly available, durable Ceph storage in your Kubernetes cluster. If you have any questions along the way, please don'

rook.io

 

 


그럼... 설치를 시작해보자 !

 

설명은 위 공식 문서에 있으니까, 설정을 생략하고 명령만 적어 놓겠다. 

그냥 아래 명령어를 따라 수행하면 된다. 

 

Ceph 설치 전에 준비할 내용:
  Kubernetes worker node에 Ceph가 Storage로 사용할 Raw device가 있어야 한다.
  (즉, 한번도 사용하지 않은 깨끗한 SSD, HDD 같은 것이 필요하다. Format이 안 되어 있어서 Filesystem도 없는 상태면 딱 좋다.)
  나는 깡통 qcow2 이미지를 각 worker node의 Virtual disk로 사용했다.
  그리고 Ceph는 3-node cluster로 구성할 것이니까, worker node 3개에 각각 Raw device가 1개씩 있어야 한다.

모든 worker node에 Raw device를 추가 장착했다면, 아래와 같이 `lsblk -f` 명령을 수행하여 깡통 상태의 Storage가 있는지 확인한다.

아래 명령 결과에서 vdb가 아무도 사용하지 않는, 그리고 formatting도 하지 않은 완전한 깡통 상태의 Storage 이다.

$  lsblk -f

NAME                  FSTYPE      LABEL UUID                                   MOUNTPOINT
vda
└─vda1                LVM2_member       >eSO50t-GkUV-YKTH-WsGq-hNJY-eKNf-3i07IB
  ├─ubuntu--vg-root   ext4              c2366f76-6e21-4f10-a8f3-6776212e2fe4   /
  └─ubuntu--vg-swap_1 swap              9492a3dc-ad75-47cd-9596-678e8cf17ff9   [SWAP]

vdb    ## <- 이 "vdb" 저장 장치와 같이 아무 설정도 없는 상태의 Storage가 있어야 한다.

$

모든 workder node에서 위 명령으로 vdb storage 정보를 확인했다면, 이제 본격적으로 설치 작업을 한다.

 

 

아래 명령은 kubernetes bastion node 또는 kubectl 수행이 가능한 PC에서 수행한다.
########################################################################
## GitHub에서 Rook operator를 내려 받는다.
########################################################################
$  git clone --single-branch --branch v1.10.10 https://github.com/rook/rook.git

$  cd rook/deploy/examples


########################################################################
## Rook operator 운영에 필요한 custom resource definition을 생성하고
## Rook operator 리소스를 kubernetes cluster에 배포한다.
########################################################################
$  kubectl create -f crds.yaml -f common.yaml -f operator.yaml

########################################################################
## 참고:
##   내가 테스트할 때, 위 명령으로 ceph operator를 구동하고, 바로 아래의 cluster를
##   구축하려고 하니까 OSD orchestration 단계에서 실패했다.
##   정확한 원인은 모르겠는데, operator 구동 시작 후 20초 정도 기다렸다가 cluster 구축
##   하는 명령을 수행하면 오류없이 잘 cluster가 구축되었다.
########################################################################

########################################################################
## rook-ceph-operator pod가 running 상태인지 확인한다.
########################################################################
$  kubectl -n rook-ceph get pod


########################################################################
## Ceph cluster를 생성한다.
########################################################################
$  kubectl create -f cluster.yaml

########################################################################
## 주의:
##   내가 사용한 CPU는 "Intel(R) Xeon(R) E-2124G CPU @ 3.40GHz" 인데,
##   이 CPU를 사용했을 때 Ceph cluster 구성이 완료되려면 대략 3분 정도 시간이 걸렸다.
##   따라서, 아래와 같이 rook-ceph-operator 로그를 보면서 진행 과정을 보는 것이 좋다.
##   대략 3분 정도 로그가 올라가다가 마지막 부분에 "op-osd: finished .... "
##   이런 문구가 출력되면 작업이 끝난 것이다.
########################################################################
$  kubectl -n rook-ceph logs -l app=rook-ceph-operator -f

... 중간 생략 ...

2023-01-06 07:05:19.680387 I | cephclient: successfully disallowed pre-quincy osds and enabled all new quincy-only functionality
2023-01-06 07:05:19.681868 I | op-osd: finished running OSDs in namespace "rook-ceph"
2023-01-06 07:05:19.682577 I | ceph-cluster-controller: done reconciling ceph cluster in namespace "rook-ceph"

<< 위 문장이 출력되면, 끝난 것이다. Ctrl+C 키를 눌러서 kubectl log 명령을 종료시킨다 >>

########################################################################
## 만약 3분이 지났는데 'done reconciling ceph cluster ..." 로그가 출력되지 않는다면
## cluster, operator, crds를 모두 삭제하고 다시 시작해야 한다.
##  (예: kubectl delete -f cluster.yaml -f operator.yaml -f ...)
########################################################################

########################################################################
## Ceph 관련 pod가 running 상태인지 확인한다.
########################################################################
$  kubectl -n rook-ceph get pod
NAME                                                 READY   STATUS      RESTARTS   AGE
csi-cephfsplugin-provisioner-d77bb49c6-n5tgs         5/5     Running     0          140s
csi-cephfsplugin-provisioner-d77bb49c6-v9rvn         5/5     Running     0          140s
csi-cephfsplugin-rthrp                               3/3     Running     0          140s
csi-rbdplugin-hbsm7                                  3/3     Running     0          140s
csi-rbdplugin-provisioner-5b5cd64fd-nvk6c            6/6     Running     0          140s
csi-rbdplugin-provisioner-5b5cd64fd-q7bxl            6/6     Running     0          140s
rook-ceph-crashcollector-minikube-5b57b7c5d4-hfldl   1/1     Running     0          105s
rook-ceph-mgr-a-64cd7cdf54-j8b5p                     1/1     Running     0          77s
rook-ceph-mon-a-694bb7987d-fp9w7                     1/1     Running     0          105s
rook-ceph-mon-b-856fdd5cb9-5h2qk                     1/1     Running     0          94s
rook-ceph-mon-c-57545897fc-j576h                     1/1     Running     0          85s
rook-ceph-operator-85f5b946bd-s8grz                  1/1     Running     0          92m
rook-ceph-osd-0-6bb747b6c5-lnvb6                     1/1     Running     0          23s
rook-ceph-osd-1-7f67f9646d-44p7v                     1/1     Running     0          24s
rook-ceph-osd-2-6cd4b776ff-v4d68                     1/1     Running     0          25s
rook-ceph-osd-prepare-node1-vx2rz                    0/2     Completed   0          60s
rook-ceph-osd-prepare-node2-ab3fd                    0/2     Completed   0          60s
rook-ceph-osd-prepare-node3-w4xyz                    0/2     Completed   0          60s


########################################################################
## Rook toolbox를 이용하여 Ceph cluster 상태 정보를 조회한다.
##   toolbox에 대한 자세한 설명은 아래 Web document를 확인
##     https://rook.io/docs/rook/v1.10/Troubleshooting/ceph-toolbox/
########################################################################

########################################################################
## Rook toolbox를 설치한다.
########################################################################
$  kubectl create -f deploy/examples/toolbox.yaml


########################################################################
## Rook toolbox pod 내부에서 `ceph status` 명령을 수행하여 ceph cluster 상태를 조회한다.
########################################################################
$  kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash
  
bash-4.4$ ceph status
  cluster:
    id:     661d89a0-d4c5-432b-97d7-6a4d06beaf52
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum a,b,d (age 10m)
    mgr: b(active, since 11m), standbys: a
    osd: 3 osds: 3 up (since 10m), 3 in (since 11m)

  data:
    pools:   1 pools, 1 pgs
    objects: 2 objects, 449 KiB
    usage:   62 MiB used, 750 GiB / 750 GiB avail
    pgs:     1 active+clean

bash-4.4$
bash-4.4$
bash-4.4$
bash-4.4$ ceph df
--- RAW STORAGE ---
CLASS     SIZE    AVAIL    USED  RAW USED  %RAW USED
hdd    750 GiB  750 GiB  62 MiB    62 MiB          0
TOTAL  750 GiB  750 GiB  62 MiB    62 MiB          0

--- POOLS ---
POOL  ID  PGS   STORED  OBJECTS     USED  %USED  MAX AVAIL
.mgr   1    1  449 KiB        2  1.3 MiB      0    237 GiB

bash-4.4$ exit

$

 

 

예제 App을 이용하여 Ceph 동작 유무를 확인한다.

 

 

###############################################################################
## `git clone`한 소스 코드에 examples 디렉토리가 있다.
## examples 디렉토리로 이동하여 예제 App을 구동해보자.
## 당연히, 위 Ceph에서 PV를 할당받는 예제이다.
###############################################################################
$  cd /deploy/examples

###############################################################################
## 예제 App이 사용할 StorageClass를 생성한다.
###############################################################################
$  kubectl apply -f csi/rbd/storageclass.yaml
cephblockpool.ceph.rook.io/replicapool created
storageclass.storage.k8s.io/rook-ceph-block created

$  kubectl create -f mysql.yaml
service/wordpress-mysql created
persistentvolumeclaim/mysql-pv-claim created
deployment.apps/wordpress-mysql created

$  kubectl get pvc
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
mysql-pv-claim   Bound    pvc-6d458ff1-54bf-4f34-b010-a0f4b2a0966e   20Gi       RWO            rook-ceph-block   94s

$  kubectl create -f wordpress.yaml
service/wordpress created
persistentvolumeclaim/wp-pv-claim created
deployment.apps/wordpress created

$  kubectl get pod
NAME                               READY   STATUS    RESTARTS   AGE
wordpress-7cf5c5c8b-5cgqk          1/1     Running   0          42s
wordpress-mysql-6f99c59595-9vs7z   1/1     Running   0          4m8s

$  kubectl get svc  wordpress
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
wordpress         LoadBalancer   10.96.232.248   10.1.4.160    80:31494/TCP   27s

 

참고로, wordpress pod가 구동되고 1분 정도 경과된 후에 Web browser로 접속하는 것이 좋다.
(wordpress가 MySQL DB에  초기 설정값을 만드느라 시간을 좀 쓰는 듯...)

 

Web browser를 이용하여 EXTERNAL-IP에 출력된 주소로 접속해보자.

아래처럼 Wordpress 설정 화면이 출력되면, 정상 동작하는 것이다.

 

 

 

Ceph를 설치하고, Storage를 할당 받아서 PV(Persistent Volume)을 사용하는 것까지 완벽하게 동작한다.

 

 


 

Ceph Dashboard

아래의 Web Docs를 보고 따라 설정하면 된다.

 

1) Prometheus를 먼저 설치한다.

 

Prometheus Monitoring - Rook Ceph Documentation

Prometheus Monitoring Each Rook Ceph cluster has some built in metrics collectors/exporters for monitoring with Prometheus. If you do not have Prometheus running, follow the steps below to enable monitoring of Rook. If your cluster already contains a Prome

rook.io

2) Dashboard를 설치한다.

 

Ceph Dashboard - Rook Ceph Documentation

Ceph Dashboard The dashboard is a very helpful tool to give you an overview of the status of your Ceph cluster, including overall health, status of the mon quorum, status of the mgr, osd, and other Ceph daemons, view pools and PG status, show logs for the

rook.io

 

위 설명을 따라하면, 아래와 같이 Web UI, Dashboard를 볼 수 있다.

Ceph Dashboard / Cluster 상태 정보 조회

 

Ceph Dashboard / OSD 정보 조회

 

Ceph Dashboard / Pool list 조회


 

참고: Ceph 관련하여 읽으면 도움이 되는 문서

SKT TACO(Openstack) 개발자가 직접 Ceph를 설치하면서 작성한 블로그. 

 

K8S 클러스터의 영구저장소로 ceph 사용하기

 

devocean.sk.com

 

 

SKT Kubernetes solution(TKS) 개발자 "엄주관" 님이 직접 Rook를 이용하여 Ceph 및 예제 앱을 설치하면서 작성한 블로그.  

 

Kubernetes 스토리지 오퍼레이터 Rook 맛보기

 

devocean.sk.com

 

 


 

 

 

 

##
## 채용 관련 글
##
제가 일하고 있는 기업 부설연구소에서 저와 같이 연구/개발할 동료를 찾고 있습니다.
(이곳은 개인 블로그라서 기업 이름은 기재하지 않겠습니다. E-mail로 문의주시면 자세한 정보를 공유하겠습니다.)

근무지 위치:
  서울시 서초구 서초동, 3호선 남부터미널역 근처 (전철역 출구에서 회사 입구까지 도보로 328m)
필요한 지식 (아래 내용 중에서 70% 정도를 미리 알고 있다면 빠르게 협업할 수 있음):
  - 운영체제 (학부 3~4학년 때, 컴퓨터공학 운영체제 과목에서 배운 지식 수준):
    예를 들어, Processor, Process 생성(Fork)/종료, Memory, 동시성, 병렬처리, OS kernel driver  
  - Linux OS에서 IPC 구현이 가능
    예를 들어, MSGQ, SHM, Named PIPE 등 활용하여 Process간 Comm.하는 기능 구현이 가능하면 됨. 
  - Algorithm(C언어, C++ 언어로 구현 가능해야 함)
    예를 들어, Hashtable, B-Tree, Qsort 정도를 C 또는 C++로 구현할 수 있을 정도 
  - Network 패킷 처리 지식(Layer 2 ~ 4, Layer 7)
    예를 들어, DHCP Server/Client의 주요 Feature를 구현할 정도의 능력이 있으면 됨.
  - Netfilter, eBPF 등 (IP packet hooking, ethernet packet 처리, UDP/TCP packet 처리)
  - IETF RFC 문서를 잘 읽고 이해하는 능력 ^^
  # 위에 열거한 내용 외에도 제가 여기 블로그에 적은 내용들이 대부분 업무하면서 관련이 있는 주제를 기록한 것이라서
  # 이 블로그에 있는 내용들을 잘 알고 있다면, 저희 연구소에 와서 연구/개발 업무를 수행함에 있어서 어려움이 없을 겁니다.
회사에서 사용하는 프로그래밍 언어:
  - 프로그래밍 언어: C, C++, Go
    (참고: 아직 연구소 동료들이 Rust를 사용하진 않습니다만, 새 언어로써 Rust를 사용하는 것을 고려하는 중)
근무 시간:
  - 출근: 8~10시 사이에서 자유롭게 선택
  - 퇴근: 8시간 근무 후 퇴근 (오후 5시 ~ 7시 사이)
  - 야근 여부: 거의 없음 (내 경우, 올해 상반기 6개월간 7시 이후에 퇴근한 경우가 2회 있었음)
  - 회식 여부: 자유 (1년에 2회 정도 회식하는데, 본인이 집에 가고 싶으면 회식에 안 감. 왜 참석 안 하는지 묻지도 않음)
외근 여부:
  - 신규 프로젝트 멤버 -> 외근 전혀 하지 않음 (나는 신규 프로젝트만 참여해서 지난 1년 동안 한번도 외근 없었음)
  - 상용 프로젝트 멤버 -> 1년에 5회 미만 정도로 외근
팀 워크샵 여부:
  - 팀 워크샵 자체를 진행하지 않음. (워크샵 참석하는 거 싫어하는 개발자 환영 ^^)
연락처:
  - "sejong.jeonjo@gmail.com"  # 궁금한 점은 이 연락처로 문의주세요.
  - 블로그 비밀 댓글 (제가 하루에 한번씩 댓글 확인하고 있음)
원하는 인재상:
  - 우리 부설연구소는 "긴 호흡으로 프로젝트를 진행"하기 때문에 최소 2년간 한 가지 주제를 꾸준하게 연구/개발할 수 있는 개발자를 원함.
  - 우리 부설연구소는 자주적으로 연구 주제를 찾아서 업무를 하기 때문에 능동적으로 생각하고 행동하는 동료를 원함.
  - 차분하게 연구 주제에 몰입하고, 해법을 찾는 것을 즐기는 사람.
내가 느끼는 우리 연구소의 장점:
  - 갑/을 관계가 없음. (제가 근무하고 있는 연구소는 SI업종이 아니라서 갑/을 회사 개념이 없음)
  - 연구소 자체적으로 연구 주제를 발굴하고 시스템을 개발하기 때문에 개발 일정에 대한 스트레스가 적음
  - 빌딩 전체를 우리 회사가 사용하므로 분위기가 산만하지 않음.
  - 근처에 예술의전당, 우면산 둘레길이 있어서 점심 시간에 산책하기 좋음 ^^
  - 연구소 동료들 매너가 Good (2년간 일하면서 한번도 감정에 스크레치 생기거나 얼굴 붉히며 싸운 적 없음 ^^)
반응형

 

작성일: 2024년 3월 11일

 

여담 1:
이전에는 kubeadm 명령 도구를 이용해서 kubernetes cluster를 구축했었는데,
오늘은 만사가 귀찮아서 kubespray를 이용해서 kubernetes cluster를 구축해보기로 했다.
kubespray를 이용하면 containerd, CNI, MetalLB 같은 패키지를 직접 설치하지 않아도 되니까 시간이 많이 절약된다.
Ubuntu 22.04 OS가 설치되어 있다고 가정하면, 대략 아래 절차를 따라했을 때 30분 정도 시간이 소요되는 것 같다.

 

여담 2:
아래 작업을 3가지 CPU 스펙으로 진행해봤는데, 저사양 CPU에서는 kubespray를 수행하는 중간에 실패한다.
특히 kubespray를 실행하는 노드(예를 들어 master-a 노드)의 CPU 스펙이 중요하다.
내가 테스트했던 CPU 스펙과 성공/실패 여부를 정리해보면;
CPU 스펙 Kubespray 동작 결과
Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz (16 쓰레드) K8S 클러스터 구성 성공
Intel(R) Xeon(R) E-2124G CPU @ 3.40GHz (4 쓰레드) K8S 클러스터 구성 실패
Intel(R) Core(TM) i7-11700 @ 2.50GHz (16 쓰레드) K8S 클러스터 구성 성공

 

.

.

.

 

Kubernetes cluster 구축 환경 및 Network 구성 정보  [ K8S 클러스터 설계 ]

주의:
아래 예시는 kubespray를 실행할 장비를 별도로 만들지 않았는데, 금전적으로 여유가 있거나 이미 HW가 넉넉히 있는 경우라면
kubespray 실행용 장비를 따로 가지고 있으면 좋다.
Master node: 3개 (Ubuntu 22.04)
  - CPU: 2 core
  - MEM: 8GB
  - OS: Ubuntu 22.04

Worker node: 3개 (Ubuntu 22.04)
  - CPU: 4 core
  - MEM: 16GB
  - OS: Ubuntu 22.04

##
## 참고: CPU, MEM가 적어서 master-a 장비에서 kubespray를 실행하겠다.  
##      만약, HW 제원이 넉넉하다면 kubespray를 실행할 전용 장비가 있으면 좋다.  
##

Network 구성:
  - master-a: 10.10.1.11
  - master-b: 10.10.1.12
  - master-c: 10.10.1.13
  - worker-a: 10.10.1.101
  - worker-b: 10.10.1.102
  - worker-c: 10.10.1.103

 

 

OS & 접속 계정 설정

Master node 및 Worker node로 사용할 6개의 Ubuntu 22.04 서버를 설치한다.

아래 2가지 중에서 편한 방법으로 구성하면 된다.
  - 물리 장비에 OS를 설치하거나 VM에 OS를 설치. (실제로 상용 서비스를 할 것이라면, 이 방법을 권장)
  - 단순히 학습을 목적으로 Kubernetes cluster를 설치한다면, VM에 OS를 설치하는 것을 권장.

 

[ 작업 대상 장비: master-a 노드 ]
'master-a' 에서 아래와 같이 Private key, Public key를 생성하고
이렇게 생성한 Public key를 모든 kubernetes node에 복사한다.

## 이 명령은 master-a 노드에서 수행해야 한다.

$ ssh-keygen 

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
... 생략 ...

$ ssh-copy-id  sejong@master-a
...

$ ssh-copy-id  sejong@master-b
...

$ ssh-copy-id  sejong@master-c
...

$ ssh-copy-id  sejong@worker-a
...

$ ssh-copy-id  sejong@worker-b
...

$ ssh-copy-id  sejong@worker-c
...

 

 

[ 작업 대상 장비: 모든 노드 ]

Password 없이 Root 권한을 얻기 위해 각 노드에서 아래와 같이 작업을 수행한다. (Ansible이 동작하기 위해 필요한 작업)
$ sudo -
$ echo "sejong ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

 

 

[ 작업 대상 장비: 모든 노드 ]

각 노드의 Firewall 기능이 disable되어 있는지 확인한다.
$ ufw status
Status: inactive
 
 

[ 작업 대상 장비: 모든 노드 ]

각 노드의 /etc/hosts 파일에 아래의 내용을 추가한다.
$ cat /etc/hosts

... 중간 생략 ...

10.10.1.11 master-a
10.10.1.12 master-b
10.10.1.13 master-c

10.10.1.101 worker-a
10.10.1.102 worker-b
10.10.1.103 worker-c

... 중간 생략 ...
 

Kubespray 실행을 위한 준비 작업

[ 작업 대상 장비: master-a 노드 ]

$ sudo -s

$ apt update

$ apt install python3-pip

$ git clone https://github.com/kubernetes-sigs/kubespray.git

$ cd kubespray

$ pip3 install -r requirements.txt

$ cd inventory

$ cp -Rp sample/ mycluster


$ cat hosts.yaml

all:
  hosts:
    master-a:
      ansible_host: master-a
    master-b:
      ansible_host: master-b
    master-c:
      ansible_host: master-c
    worker-a:
      ansible_host: worker-a
    worker-b:
      ansible_host: worker-b
    worker-c:
      ansible_host: worker-c      
  children:
    kube_control_plane:
      hosts:
        master-a:
        master-b:
        master-c:
    kube_node:
      hosts:
        worker-a:
        worker-b:
        worker-c:
    etcd:
      hosts:
        master-a:
        master-b:
        master-c:
    k8s_cluster:
      children:
        kube_control_plane:
        kube_node:
        calico_rr:
    calico_rr:
      hosts: {}


$ cat  ./group_vars/k8s_cluster/k8s-cluster.yml

... 중간 생략 ...

## Kube cluster를 구축하고 나서, MetalLB를 설치할 때 strict_arp 설정이 필요하다.
## 따라서 MetalLB를 설치하려는 경우라면, 아래 설정을 꼭 'true'로 변경해야 한다.
kube_proxy_strict_arp: true
... 중간 생략 ...
container_manager: containerd
... 중간 생략 ...
kubernetes_audit: true
... 중간 생략 ...

$

 

 

Kubespray 실행하기 (Kubernetes Cluster 생성하기)

[ 작업 대상 장비: master-a 노드 ]

##
## kubespray 소스 폴더의 최상위 폴더로 이동 후 아래 명령을 실행
## (참고) root 계정, 일반 계정 어떤 것으로 ansible-playbook 명령을 실행해도 괜찮다.
##       단, 위에서 public key를 모든 노드에 복사(ssh-copy-id)할 때 어떤 계정의 public key를
##       사용했느냐에 따라 동일한 계정으로 아래 명령을 수행하면 된다.
##

$ ansible-playbook -v -i inventory/mycluster/hosts.yaml --become --become-user=root cluster.yml

... 중간 생략 ...

TASK [network_plugin/calico : Set calico_pool_conf] *****************************************************************************************************************************************
ok: [master-a] => {"ansible_facts": {"calico_pool_conf": {"apiVersion": "projectcalico.org/v3", "kind": "IPPool", "metadata": {"creationTimestamp": "2024-03-08T15:06:52Z", "name": "default-pool", "resourceVersion": "4122", "uid": "ffb5f2e0-85f1-4f3b-9c9d-55fe86be8c97"}, "spec": {"allowedUses": ["Workload", "Tunnel"], "blockSize": 26, "cidr": "10.233.64.0/18", "ipipMode": "Never", "natOutgoing": true, "nodeSelector": "all()", "vxlanMode": "Always"}}}, "changed": false}
Friday 08 March 2024  15:29:07 +0000 (0:00:00.054)       0:19:02.007 **********

TASK [network_plugin/calico : Check if inventory match current cluster configuration] *******************************************************************************************************
ok: [master-a] => {
    "changed": false,
    "msg": "All assertions passed"
}
Friday 08 March 2024  15:29:07 +0000 (0:00:00.060)       0:19:02.067 **********
Friday 08 March 2024  15:29:07 +0000 (0:00:00.037)       0:19:02.104 **********
Friday 08 March 2024  15:29:07 +0000 (0:00:00.045)       0:19:02.150 **********

PLAY RECAP **********************************************************************************************************************************************************************************
master-a                   : ok=676  changed=35   unreachable=0    failed=0    skipped=1164 rescued=0    ignored=2
master-b                   : ok=580  changed=25   unreachable=0    failed=0    skipped=1046 rescued=0    ignored=1
master-c                   : ok=582  changed=25   unreachable=0    failed=0    skipped=1044 rescued=0    ignored=1
worker-a                   : ok=419  changed=8    unreachable=0    failed=0    skipped=695  rescued=0    ignored=1
worker-b                   : ok=419  changed=8    unreachable=0    failed=0    skipped=691  rescued=0    ignored=1
worker-c                   : ok=419  changed=8    unreachable=0    failed=0    skipped=691  rescued=0    ignored=1

Friday 08 March 2024  15:29:07 +0000 (0:00:00.309)       0:19:02.459 **********
===============================================================================
kubernetes/kubeadm : Restart all kube-proxy pods to ensure that they load the new configmap ----------------------------------------------------------------------------------------- 71.14s
network_plugin/calico : Check if calico ready --------------------------------------------------------------------------------------------------------------------------------------- 69.41s
kubernetes-apps/ansible : Kubernetes Apps | Start Resources ------------------------------------------------------------------------------------------------------------------------- 65.75s
network_plugin/calico : Calico | Create Calico Kubernetes datastore resources ------------------------------------------------------------------------------------------------------- 41.63s
kubernetes/control-plane : Upload certificates so they are fresh and not expired ---------------------------------------------------------------------------------------------------- 35.07s
etcd : Configure | Wait for etcd cluster to be healthy ------------------------------------------------------------------------------------------------------------------------------ 29.78s
kubernetes/preinstall : Preinstall | restart kube-apiserver crio/containerd --------------------------------------------------------------------------------------------------------- 27.93s
policy_controller/calico : Start of Calico kube controllers ------------------------------------------------------------------------------------------------------------------------- 26.35s
etcd : Reload etcd ------------------------------------------------------------------------------------------------------------------------------------------------------------------ 21.45s
kubernetes/preinstall : Preinstall | restart kube-controller-manager crio/containerd ------------------------------------------------------------------------------------------------ 20.39s
network_plugin/calico : Calico | Configure calico network pool ---------------------------------------------------------------------------------------------------------------------- 15.41s
network_plugin/calico : Start Calico resources -------------------------------------------------------------------------------------------------------------------------------------- 14.03s
kubernetes/control-plane : Create kubeadm token for joining nodes with 24h expiration (default) ------------------------------------------------------------------------------------- 13.13s
etcd : Wait for etcd up ------------------------------------------------------------------------------------------------------------------------------------------------------------- 12.82s
container-engine/runc : Download_file | Download item ------------------------------------------------------------------------------------------------------------------------------- 12.65s
container-engine/crictl : Download_file | Download item ----------------------------------------------------------------------------------------------------------------------------- 12.60s
container-engine/containerd : Download_file | Download item ------------------------------------------------------------------------------------------------------------------------- 12.17s
kubernetes/control-plane : Check which kube-control nodes are already members of the cluster ---------------------------------------------------------------------------------------- 11.68s
container-engine/nerdctl : Download_file | Download item ---------------------------------------------------------------------------------------------------------------------------- 11.57s
etcd : Backup etcd v2 data ---------------------------------------------------------------------------------------------------------------------------------------------------------- 11.29s

$

 

[ 참고 ]
가끔 위 ansible-playbook 명령이 실패하는 경우가 있다.
그럴 때는 동일하게 한번 더 실행하면 해결되는 경우가 많다. (특히, CPU와 Memory 성능이 낮은 경우)

 

위 Ansible playbook이 정상적으로 수행되었다면,
아래와 같이 root 계정 권한으로 kubectl 명령을 수행해본다.

 

$ sudo -s

$ kubectl get node -o wide

NAME       STATUS   ROLES           AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
master-a   Ready    control-plane   35m   v1.29.2   172.17.1.11    <none>        Ubuntu 22.04.4 LTS   5.15.0-100-generic   containerd://1.7.13
master-b   Ready    control-plane   34m   v1.29.2   172.17.1.12    <none>        Ubuntu 22.04.4 LTS   5.15.0-100-generic   containerd://1.7.13
master-c   Ready    control-plane   33m   v1.29.2   172.17.1.13    <none>        Ubuntu 22.04.4 LTS   5.15.0-100-generic   containerd://1.7.13
worker-a   Ready    <none>          31m   v1.29.2   172.17.1.101   <none>        Ubuntu 22.04.4 LTS   5.15.0-100-generic   containerd://1.7.13
worker-b   Ready    <none>          31m   v1.29.2   172.17.1.102   <none>        Ubuntu 22.04.4 LTS   5.15.0-100-generic   containerd://1.7.13
worker-c   Ready    <none>          31m   v1.29.2   172.17.1.103   <none>        Ubuntu 22.04.4 LTS   5.15.0-100-generic   containerd://1.7.13


$ kubectl get pod -A

NAMESPACE     NAME                                      READY   STATUS              RESTARTS         AGE
kube-system   calico-kube-controllers-648dffd99-l9pnt   1/1     Running             0                12m
kube-system   calico-node-4q5q9                         1/1     Running             11 (18m ago)     31m
kube-system   calico-node-98pdw                         1/1     Running             14 (5m52s ago)   31m
kube-system   calico-node-nrn9h                         1/1     Running             12 (7m57s ago)   31m
kube-system   calico-node-wgpvw                         1/1     Running             11 (18m ago)     31m
kube-system   coredns-69db55dd76-zkfqn                  1/1     Running             0                10m
kube-system   dns-autoscaler-6f4b597d8c-rt9nk           1/1     Running             0                10m
kube-system   kube-apiserver-master-a                   1/1     Running             4 (18m ago)      37m
kube-system   kube-apiserver-master-b                   1/1     Running             4 (18m ago)      36m
kube-system   kube-apiserver-master-c                   1/1     Running             4 (16m ago)      35m
kube-system   kube-controller-manager-master-a          1/1     Running             8 (6m27s ago)    37m
kube-system   kube-controller-manager-master-c          1/1     Running             10 (7m48s ago)   35m
kube-system   kube-proxy-hgt5x                          1/1     Running             0                15m
kube-system   kube-proxy-j26c8                          1/1     Running             0                15m
kube-system   kube-proxy-ldlb7                          1/1     Running             0                13m
kube-system   kube-proxy-trhgl                          1/1     Running             0                15m
kube-system   kube-proxy-vh6qt                          1/1     Running             0                15m
kube-system   kube-proxy-wv48f                          1/1     Running             0                13m
kube-system   kube-scheduler-master-a                   1/1     Running             7 (10m ago)      37m
kube-system   kube-scheduler-master-b                   1/1     Running             7 (6m15s ago)    36m
kube-system   kube-scheduler-master-c                   1/1     Running             7 (11m ago)      35m
kube-system   nginx-proxy-worker-a                      1/1     Running             0                34m
kube-system   nginx-proxy-worker-b                      1/1     Running             0                34m
kube-system   nginx-proxy-worker-c                      1/1     Running             0                32m
kube-system   nodelocaldns-42f6z                        1/1     Running             0                10m
kube-system   nodelocaldns-5nqjw                        1/1     Running             0                10m
kube-system   nodelocaldns-dsg5w                        1/1     Running             0                10m
kube-system   nodelocaldns-dz9tm                        1/1     Running             0                10m
kube-system   nodelocaldns-mxjxz                        1/1     Running             0                10m
kube-system   nodelocaldns-zqb6h                        1/1     Running             0                10m

$ kubectl get svc -A

NAMESPACE     NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
default       kubernetes   ClusterIP   10.233.0.1   <none>        443/TCP                  37m
kube-system   coredns      ClusterIP   10.233.0.3   <none>        53/UDP,53/TCP,9153/TCP   12m
$

 

 

 

Kubespray ansible playbook은 11분 42초가 소요되었는데,

조금 더 최신 컴퓨터로 ansible playbook을 실행했다면 10분 이내에 모든 cluster 구축이 완료되지 않을까...

 

[ 참고: 이번 테스트에 사용했던 HW 1 사양 ]

$ lshw -short

H/W path           Device           Class          Description
==============================================================
... 중간 생략 ...
/0/3b                               memory         64GiB System Memory
/0/52                               processor      11th Gen Intel(R) Core(TM) i7-11700 @ 2.50GHz
/0/100/1/0                          display        GA102 [GeForce RTX 3080 Ti]
/0/100/6/0         /dev/nvme0       storage        Samsung SSD 980 PRO 1TB
... 중간 생략 ...

 

[ 참고: 이번 테스트에 사용했던 HW 2 사양 ]

$  lshw -short

H/W path          Device     Class          Description
=======================================================
/0/3a                      memory         64GiB System Memory
/0/3a/0                    memory         32GiB SODIMM DDR4 Synchronous 3200 MHz (0.3 ns)
/0/3a/2                    memory         32GiB SODIMM DDR4 Synchronous 3200 MHz (0.3 ns)
/0/48                      processor      Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz
... 중간 생략 ...

 


 

예제 Pod, Service를 배포하기

아래 글에 간단하게 Pod, Service 리소스를 생성하는 예제 코드 및 명령이 있다.

https://andrewpage.tistory.com/68

 

 


 

 

 

Troubleshooting, Q&A

 

Kubernetes cluster 초기화 하기

$ ansible-playbook -v -i inventory/mycluster/hosts.yaml --become --become-user=root reset.yml

 

Kubernetes cluster 를 upgrade 하기

Upgrade 시나리오가 다양하기 때문에 아래 글을 자세히 읽고 Upgrade를 수행하는 것을 권장한다.

https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md

 

Kubernetes node를 추가, 대체하기 (Join new node, Replace node)

Kubernetes node에 대한 operation이 다양하기 때문에 아래 글을 자세히 읽고 node 관리하는 것을 권장한다.

https://github.com/kubernetes-sigs/kubespray/blob/master/docs/nodes.md

 

 

 

 

 

블로그 작성자: sejong.jeonjo@gmail.com

 

 

반응형

 

준비 작업: Oracle Cloud 사용을 위한 계정 생성

아래 Web Page에서 Oracle Cloud 사용을 위해서 Account를 생성한다.

https://cloud.oracle.com/

 

내 경우, 계정 생성하다가 마지막 "검증" 단계에서 실패했는데  Oracle에 전화해서 물어보니 

요즘 Block Chain Mining을 위해 Cloud Infra를 악용하는 사례가 있어서

계정 생성시 입력한 정보 중에서 블랙 해커로 의심되는 정보가 있으면, Oracle Machine Learning이 계정 생성을 Blocking 한다고 설명해줬다.

혹시 계정 생성하다 실패하면, 계정 정보를 다르게 해서 다시 생성하는 것이 정신 건강에 좋다.

 

 

OKE Cluster 생성하기

Oracle Cloud의 TOP 메뉴에서

[ Developer Services ] -> [ Kubernetes Cluters (OKE) ]

순서로 메뉴를 클릭하고, Quick Start 방식로 몇 가지 기본 설정 값만 정해주면 너무나 간단하게 Kubernetes Cluster가 생성된다.

 

주의: 
동일한 Spec의 Cluster 구축이라고 하더라도 Cluster Infra 상황에 따라 어떤 경우는 5분만에 Cluster가 생성되고,
어떤 경우는 15분이 넘도록 Cluster 생성이 완료되지 않는다.
그래서 마음편하게, Cluster 생성 버튼을 누르고 20분 정도 다른 업무를 하다가 오는 것이 좋다.

 

내 PC (Macbook)에서 OKE Cluster에 접근하기 (Bastion 구성)

Oracle이 너무 간단하게 만들어 놓아서 굳이 장황하게 설명할게 없다.

아래 Web Page에서 아래 빨간 번호 순서로 따라 하기만 하면 된다.

당연한 말이겠지만, 내 Macbook은 Public Network을 통해서 Oracle Cloud Infra에 접근해야 하니까, 아래 그림의 (6)번 절차에서 "VNC-Native public endpoint"와 관련된 명령을 복사해서 내 Macbook의 iTerm에 붙여 넣어야 한다.

 

 

위 절차를 끝낸 후, 내 Macbook의 iTerm 터미널에서 아래와 같이 명령을 수행하면 명령이 잘 수행되는 것을 확인할 수 있다.

 

$  kubectl  get node
NAME          STATUS   ROLES   AGE     VERSION
10.0.10.121   Ready    node    3m7s    v1.24.1
10.0.10.124   Ready    node    2m59s   v1.24.1
10.0.10.127   Ready    node    2m55s   v1.24.1
$

 

 

주의:
위 절차를 따라할 때, (5) ~ (6) 단계 사이에서 아래의 명령을 한번 수행해야 한다.
기존에 사용하던 KUBECONFIG 환경 변수가 설정된 경우라면, (6) 단계가 실패한다.
$  unset KUBECONFIG

 

 

 

Tip:
  [ Multi cluster를 운영하는 경우 ]
  예를 들어서 OKE kubernetes에서 cluster2, cluster3 등 2개의 cluster를 생성하여 운영하는 경우라면
  아래와 같이 .kube/config 파일 이름을 변경해서 사용하는 것을 추천.

 

$ mv $KUBECONFIG/config $KUBECONFIG/config.cluster2


$ cat .bashrc

... 중간 생략 ...

function use-oke-cluster2() {
  AA=$(printf "\033[")
  export KUBECONFIG=~/.kube/config.cluster2
  echo "${AA}32m"
  echo "Cluster Name      :" $(cat $KUBECONFIG | yq '.clusters[0].name')
  echo "Cluster API Server:" $(cat $KUBECONFIG | yq '.clusters[0].cluster.server')
  echo "${AA}0m"
}

... 중간 생략 ...

$ use-oke-cluster2

Cluster Name      : cluster-cja9kqodr9l
Cluster API Server: https://193.135.212.37:6443

$ kubectl get node
NAME          STATUS   ROLES   AGE    VERSION
10.0.10.115   Ready    node    11d    v1.25.4
10.0.10.117   Ready    node    11d    v1.25.4
$
반응형

Openshift 4.10 인증, 권한에 관해 자세히 알고 싶다면, 아래 Red Hat 공식 Web Docs를 읽어 보자!

 

(한국어 문서)

https://access.redhat.com/documentation/ko-kr/openshift_container_platform/4.10/html-single/authentication_and_authorization/index

 

인증 및 권한 부여 OpenShift Container Platform 4.10 | Red Hat Customer Portal

이 문서에서는 OpenShift Container Platform에서 ID 공급자를 정의하는 방법을 설명합니다. 또한 클러스터를 보호하기 위해 역할 기반 액세스 제어를 구성하는 방법도 알아봅니다.

access.redhat.com

 

 

(영어 문서)

https://access.redhat.com/documentation/en-us/openshift_container_platform/4.10/html-single/authentication_and_authorization/index

 

Authentication and authorization OpenShift Container Platform 4.10 | Red Hat Customer Portal

This document provides instructions for defining identity providers in OpenShift Container Platform. It also discusses how to configure role-based access control to secure the cluster.

access.redhat.com

 

+ Recent posts