반응형

 

안녕하세요. Solutions Architect(AWS) 제니입니다😀

오랜만에 글을 적어봅니다. 글 제목 분류인 [PKOS]는 Production Kubernetes Online Study의 약어입니다. 우연한 기회로 외부 스터디를 알게 되어서 앞으로 약 7주간 매주 일요일 저녁 8~10시에 쿠버네티스 스터디를 하고 학습 과제까지 완료한 뒤 내용 정리를 포스팅해볼 예정입니다. 매주 실습 결과를 제출해야 하고 과제도 있는데, 1주 차라도 과제를 완료하지 못하면 자동 탈락처리 된다고 하여.. 정말 빡세게 해 볼 계획입니다. 취업 후 바빠서 업로드하지 못했던 블로그도 다시 살릴 겸, 새해 버프를 받아서 달려봐요!

 

 

 

1주차 : AWS kOps 설치 및 기본 사용

 

 

  • 기초 지식 : AWS 기초(VPC, ELB, EBS/EFS/S3, IAM)
  • 옵션/심화 : 컨테이너 격리 & 도커 네트워크, 쿠버네티스 특징 & 기초
  • 스터디 교재 : 24단계 실습으로 정복하는 쿠버네티스

 

1주 차부터 많은 내용을 진행했는데, 스터디 모임장인 가시다님이 준비해주신 핸즈온을 통해 놓친 부분들을 쉽게 따라갈 수 있었습니다.

 

 

[쿠버네티스 기초]

여기서 제일 중요하게 느껴졌던 포인트는 '멱등성(Reconciler)'입니다.

여러 번 실행하더라도 같은 결과가 나오는 것을 멱등성이라고 합니다. 많은 내용이 담겨있는 스크립트 파일이 중간에 멈췄다가 다시 재실행된다면? 이미 실행된 부분에 대해서 또다시 시작하게 되고 소스가 꼬일 수 있습니다. 이런 부분을 방지해줄 수 있는 특징을 멱등성이라고 할 수 있습니다. 오늘 실습할 내용인 AWS kOps 배포를 하며 확인해보도록 하겠습니다.

 

 

[kOps 소개]

kOps 공식 홈페이지에 가서 보면 kOps를 다음과 같이 소개하고 있습니다.

kOps - Kubernetes Operations
The easiest way to get a production grade Kubernetes cluster up and running.

Kubernetes 클러스터를 시작하고 실행하는 가장 쉬운 방법.

한마디로 쿠버네티스 생성 및 관리를 쉽게 하도록 도와주는 오픈소스 툴이라고 합니다. 저도 이번에 공부하면서 처음 알게 되었는데요. 처음에 [케이 옵스]로 읽었다가 [콥스] 라고 하셔서 발음하는 방법도 새롭게 알아갔습니다. 낯설지만 실습을 통해 어떤 개념인지 대략적으로 잡아갈 수 있었습니다.

 

 

[아키텍처 및 kOps 배포]

AWS, Azure, GCP 등을 지원하는데 실습에서 AWS 서비스를 다룹니다.

AWS kOps Architecture

 

위 아키텍처를 배포하기 위해서 제 도메인인 jennysim.shop을 사용하고, AWS CloudFormation에 이미 작성되어 있는 yaml파일을 이용해서 기본 인프라 환경을 배포하였습니다. 이후 자동으로 kOps 클러스터 인프라를 배포하여 쉽게 설치환경을 구성하였습니다. 실습 중 중간에 배포내용을 삭제하지 않고 CloudFormation delete를 했다가 인스턴스가 종료되지 않는 상황이 있었는데요. EC2 Auto Scaling 그룹을 삭제함으로써 해결하였습니다. 처음에는 인스턴스 내부에 replica구성을 제거해야 하는 건가 싶어서 새로 생성된 인스턴스로 접근은 안되고 혼자서 삽질을 조금 했는데, EC2에 Auto Scaling구성으로 구현이 된다는 것을 알게 되었습니다.

 

  • 설치 중간에 실패 시 삭제 방법
    1. EC2 Auto Scaling 그룹 : 3개 삭제
    2. EC2 시작 템플릿 : 3개 삭제
    3. S3 버킷 비우기
    4. Route53에 추가된 A 레코드 3개 삭제
    5. CloudFormation 삭제

 

 

이후 kops-ec2 인스턴스 서버에 ssh 접속해서 테스트를 진행하였습니다. 사용 중인 노트북이 Windows라서 MobaXterm을 사용했는데, 까만 배경에 하얀 글자가 눈에 띄지 않아서 나중에 하이라이트 기능을 추가해야겠네요.

kOps 구성이 완료되어 현재 접속한 서버에서 클러스터와 인스턴스의 현재 정보를 다음과 같이 확인할 수 있었습니다.

이번 스터디의 과제 1번!

 

# kops get cluster
# kops get instances

 

Control plane과 node에도 각각 SSH로 접속해서 메타데이터들을 확인할 수 있습니다. 그리고 AWS Route53 도메인 정보도 간단하게 확인해 봤는데요. 저는 제 도메인인 jennysim.shop 도메인으로 테스트를 마쳤습니다.

 

 

[기타 : 관리 편의성]

Alias

작업 중에 kubectl 명령어를 k 입력만으로 완성할 수 있도록 alias를 사용할 수 있습니다.

# 자동 완성 및 alias 축약 설정
source <(kubectl completion bash)
echo 'source <(kubectl completion bash)' >> ~/.bashrc
echo 'alias k=kubectl' >> ~/.bashrc
echo 'complete -F __start_kubectl k' >> ~/.bashrc

 

kubectl 플러그인 : krew

kubectl의 cli 플러그인 매니저인 쿠버네티스 크루(krew)를 통해 부가적인 기능들을 제공합니다.

 

kubectl 플러그인 배포
다른 사람이 사용할 수 있는 플러그인을 개발한 경우, 이를 패키징하고, 배포하고 사용자에게 업데이트를 제공하는 방법을 고려해야 한다.

Krew
Krew는 플러그인을 패키징하고 배포하는 크로스-플랫폼 방식을 제공한다. 이렇게 하면, 모든 대상 플랫폼(리눅스, 윈도우, macOS 등)에 단일 패키징 형식을 사용하고 사용자에게 업데이트를 제공한다. Krew는 또한 다른 사람들이 여러분의 플러그인을 검색하고 설치할 수 있도록 플러그인 인덱스를 유지 관리한다.

출처 : https://kubernetes.io/ko/docs/tasks/extend-kubectl/kubectl-plugins/

 

플러그인으로 kubectl 확장

kubectl 플러그인을 작성하고 설치해서 kubectl을 확장한다.

kubernetes.io

 

What does Krew do?

Krew is a tool that makes it easy to use kubectl plugins. Krew helps you discover plugins, install and manage them on your machine. It is similar to tools like apt, dnf or brew. Today, over 200 kubectl plugins are available on Krew.

- For kubectl users: Krew helps you find, install and manage kubectl plugins in a consistent way.
- For plugin developers: Krew helps you package and distribute your plugins on multiple platforms and makes them discoverable.

출처 : https://github.com/kubernetes-sigs/krew/

 

GitHub - kubernetes-sigs/krew: 📦 Find and install kubectl plugins

📦 Find and install kubectl plugins. Contribute to kubernetes-sigs/krew development by creating an account on GitHub.

github.com

 

정리하면 Krew는 kubectl 플러그인을 쉽게 사용할 수 있는 도구입니다. 설치해서 쓸 수 있으며 apt, dnf, brew와 같은 도구와 유사합니다.  현재까지 Krew에서 200개 이상의 kubectl 플러그인을 사용할 수 있습니다. 

# 설치
curl -fsSLO https://github.com/kubernetes-sigs/krew/releases/download/v0.4.3/krew-linux_amd64.tar.gz
tar zxvf krew-linux_amd64.tar.gz
./krew-linux_amd64 install krew
tree -L 3 /root/.krew/bin

# PATH 추가
export PATH="${PATH}:/root/.krew/bin"
echo 'export PATH="${PATH}:/root/.krew/bin"' >>~/.bashrc

# krew 확인
kubectl krew
kubectl krew update
kubectl krew search
kubectl krew list
kubectl krew

 

실습에서는 krew로 df-pv, get-all, ktop, neat, oomd, view-secret을 사용해 봤습니다. krew 하나에도 정말 많은 플러그인이 있어서 나중에 잘 활용하면 편리할 것 같네요.

 

 

[svc,pod 배포 테스트 - Mario 게임 with CLB]

가시다님의 슈퍼마리오 디플로이먼트 배포 yaml파일을 받아서 정말 쉽고 간단하게 svc, pod를 배포해볼 수 있습니다.

# 수퍼마리오 디플로이먼트 배포
curl -O https://raw.githubusercontent.com/gasida/PKOS/main/1/mario.yaml
kubectl apply -f mario.yaml
cat mario.yaml | yh

# 배포 확인 : CLB 배포 확인 >> 5분 이상 소요
kubectl get deploy,svc,ep mario
watch kubectl get svc mario

# 마리오 게임 접속 : CLB 주소로 웹 접속
kubectl get svc mario -o jsonpath={.status.loadBalancer.ingress[0].hostname} | awk '{ print "Maria URL = http://"$1 }'

# 삭제
kubectl delete deploy,svc mario

 

다음 마리오 게임을 배포한 뒤 웹 주소로 접근하니 추억의 마리오 게임이 실행됩니다. 여기서는 AWS CLB를 사용합니다. 2022년 12월을 끝으로 AWS에서 CLB 서비스를 종료하려고 하기 때문에(아직 실행은 됩니다.) 실제 활용하는 곳에서는 NLB나 ALB를 사용하고 있다고 합니다.

추억의 슈퍼마리오 게임🍄

 

 

[트러블 슈팅]

언제나 발생하는 에러 상황에 대처하는 기본 조치 프로세스입니다.

get 확인 → describe 확인 → 애플리케이션 로그(log) 확인 → 클러스터 에러 이벤트(event) 확인

 

이전에 k8s 공부할 때 Vagrant를 활용해서 배포 테스트를 해봤는데요. 그때도 마찬가지로 이슈가 발생했고, describe로 히스토리를 확인해서 해결했던 경험이 있습니다. 이번 스터디를 통해 애플리케이션 로그 확인이나 클러스터 에러 이벤트 확인하는 것까지 더 자세하게 들여다볼 수 있었습니다.

 

여기서 잘못된 이미지 정보의 pod를 배포해서 디버깅해보는 테스트를 진행했습니다.

# 잘못된 이미지 정보의 파드 배포
kubectl apply -f https://raw.githubusercontent.com/junghoon2/kube-books/main/ch05/nginx-error-pod.yml

 

  • 디버깅 프로세스 : Apply → Get → Describe → Log → Event

 

프로세스에 따라 확인해서 문제의 원인은 nginx-19 이미지가 업데이트되지 않았기 때문이었습니다.

Q. 여기서 patch와 update의 차이는 무엇? patch: 일부, update: 전부

kubectl patch pod nginx-19 --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"nginx:1.19"}]'

다음과 같이 해결할 수 있었습니다.

 

 

[헬름(Helm)]

쿠버네티스를 하면서 정말 많이 들어본 헬름! 헬름이다 헬름차트다 많이 들어봤었는데요.

헬름이 무엇인지, 왜 써야 하는지 등을 아래 유튜브 강의를 통해서 개념을 잡아갈 수 있었습니다.

 

출처 : https://helm.sh/

 

What is Helm?

Helm helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application.

* 요약 : Helm은 k8s 애플리케이션을 관리하는데 도움이 됩니다.

 

한 마디로 헬름은 쿠버네티스의 패키지 관리자입니다. 패키지를 차트(Chart)라고도 표현합니다. 그래서 헬름 차트라는 말을 많이 들어본 것 같네요. 오픈소스로 공개되어 있어서 public hub의 경우 ArtifactHUB 같은 곳에서 여러 헬름 저장소를 통합해서 검색해볼 수 있습니다.

 

자세한 내용은 유튜브에!

YouTube : [인프런] 대세는 쿠버네티스 Helm편

 

 

[Helm으로 워드프레스 배포]

두 번째 과제는 'Helm으로 워드프레스를 배포해서 글 남기기'입니다.

 

먼저 helm은 ArtifactHUB에서 GUI, CLI 모두 검색이 가능합니다.

* CLI

# 아티팩트 허브에서 검색
helm search hub wordpress

* GUI

 

오픈소스 소프트웨어들을 쉽게 설치할 수 있도록 도와주는 설치 패키지 인 bitnami를 추가해 주고, wordpress 네임스페이스를 따로 생성해준 뒤에 준비된 wordpress를 배포합니다. 미리 준비된 명령들을 활용해서 손쉽게 워드프레스를 배포했고, 접속 URL을 따라 다음과 같이 두 번째 과제를 완료했습니다.

 

관리자 페이지 > 새 글 작성 완료

 

wordpress 메인 페이지

 

게시글 1개 포스팅 완료

 

 

[AWS kOps를 활용하여 워커 노드 증가(ASG = Auto Scaling Group 활용)]

세 번째 과제로 기본 node 수를 증가시키는 작업을 진행했습니다. 인스턴스 그룹 정보에 보면 각각 MIN, MAX값이 1로 설정되어 있는데요. 이 부분을 편집해서 maxSize는 3으로, minSize는 2로 수정하였습니다.

# 편집
kops edit ig nodes-ap-northeast-2a

 

이후 kops update를 완료해준 뒤 kubectl get node를 입력해주면 수분 이후에 node수가 증가한 것을 확인할 수 있습니다.

 

Updating kOps
You may want to run below commands to include fixes/features after updating kOps
kops update cluster $NAME --yes
kops rolling-update cluster $NAME --yes

출처 : https://kops.sigs.k8s.io/operations/updates_and_upgrades/

 

Updates & Upgrades - kOps - Kubernetes Operations

Updates and Upgrades Updating kOps MacOS From Homebrew: brew update && brew upgrade kops From Github: sudo rm -rf /usr/local/bin/kops wget -O kops https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/r

kops.sigs.k8s.io

 

* 결과 화면

클러스터 업데이트
rolling-update

 

# 워커노드 증가 확인
kubectl get node

node 수 확인

 

 

[실습 환경 삭제]

추가 리소스 발생을 막기 위해서 실습 환경을 삭제합니다. 먼저 kOps 클러스터 삭제를 해야 오토스케일링 그룹이 제거가 되기 때문에 먼저 삭제 후, AWS CloudFormation 스택을 제거해야 합니다.

# kOps 클러스터 삭제
kops delete cluster --yes

# 클러스터 삭제 완료 확인 후 AWS CloudFormation 스택 삭제
aws cloudformation delete-stack --stack-name mykops

 

 

글을 마치며

 

이 스터디를 입사한 지 얼마 안 되었을 때 했다면 AWS 기초 지식부터 이해해야 해서 많은 어려움이 있었을 것 같다는 생각을 해봤습니다.  물론 이 스터디의 요건이 실무자를 위한 스터디지만, 현재 1년 차 SA로서 기초적인 AWS 서비스는 사용해봤기 때문에 따라갈 만했습니다. 물론 쿠버네티스는 별개라서 학습할 내용이 참 많지만요. 핸즈온이 잘 되어있어서 너무 좋았습니다.

쿠버네티스 같은 경우 전부터 계속 관심이 있었지만 다른 프로젝트에 계속 조인되다 보니 프로젝트를 접할 기회가 없어서 우선순위에 많이 밀려 있었던 것 같아요. 만 1년을 다 채우고 난 뒤부터 Devops라는 직무가 매력적으로 다가왔습니다. 이번 기회에 스터디를 통해 쿠버네티스를 많이 접해놓으면 추후 관련된 일이 있을 때 큰 도움이 될 거라고 생각합니다.

 

쿠버네티스 하면 떠오르는 것이 오픈소스가 아닐까 싶습니다. 정말 넓고 깊은 오픈소스의 세계를 평생 가도록 다 해보긴 어렵겠지만, 쿠버네티스와 떼려야 뗄 수 없는 관계라고 생각합니다. 필요한 것들 위주로 점점 범주를 넓혀갈 수밖에 없을 것 같아요. 이번 스터디를 하면서 오픈소스가 정말 다양하게 쓰이는 것을 보았습니다.

 

1시간 동안 알차게 1주 차 내용을 차근차근 설명해주신 가시다님 강의와, 중간에는 스터디 교재 '24단계 실습으로 정복하는 쿠버네티스'의 저자 이정훈(Jerry)님의 책 후기, 경험담을 듣는 재미도 쏠쏠했습니다. 저도 언젠가는 이런 역할을 하는 시니어가 되고 싶습니다.

 

반응형

+ Recent posts