구글클라우드잼 쿠버네티스 입문반 후기

딸기잼... 포도잼.. 그리고 Google Cloud Study잼...
 

Google Cloud Study Jam은 Google Cloud 고객사의 개발자 및 엔지니어 여러분이 더욱 수월하게 GCP에 입문하실 수 있도록 돕기 위한 프로그램입니다. 참가자 여러분은 Google Cloud Study Jam이 제공하는 Qwiklabs(실습)쿠폰을 활용해 Google Cloud의 기술을 온라인 자가 학습하실 수 있습니다!
 

Google Cloud Skills Boost (Qwiklabs)

https://www.cloudskillsboost.google/journeys

Google Cloud Skills Boost

 
구글에서 친절하게 실습 쿠폰까지 제공해주면서 퀘스트 형식으로 진행하는 스터디 잼이다.

여러 과정이 있는데 그 중에서도 쿠버네티스 입문반으로 과정을 시작해보았다.
https://www.cloudskillsboost.google/quests/29

Google Cloud의 Kubernetes | Google Cloud Skills Boost

 
 

과정 기간

2023년 4월 17일(월) ~ 5월 15일(월)
 
 

목표

• GCP-Kubernetes 사용 경험 만들기
• 쿠버네티스가 뭔지 느낌 살리기
• 쿠버네티스로 무중단 배포 경험하기
• 귀여운 모자 받고 뿌듯해지기

 
 
 
실습 과정은 안내하는 순서에 따라서 콘솔에서 명령어를 입력하여 진행할 수 있다.

 
 
 

실습후기

1. GCP-Kubernetes 사용 경험 만들기

입문편은 실습 위주의 과정이지만, 초보자들을 위한 설명도 자세해서 기본적인 개념 숙지에도 도움되었다.
 

• 도커 소개
• Kubernetes 엔진: Qwik 시작
• Kubernetes로 클라우드 오케스트레이션
• Kubernetes Engine을 사용하여 배포 관리
• Kubernetes Engine의 Jenkins를 사용한 지속적 배포

과정을 5 STEP 으로 이루어져서 단계별로 학습할 수 있는 점이 좋았다.

또 중간에 실습이 제대로 이루어지고 있는지 확인하는 실습 체크란이 있어서 이를 통해 진행사항을 체크할 수 있고, 앞으로 이어질 부분에 있어 실수를 미연에 방지할 수도 있다.
 

실습 위주 과정에서는 자칫하면 사소한 실수로 막히는 경우가 생긴다. 정말 친절하게 명령어 복사까지 모두 제공해줘서 편하게 실습할 수 있었다. (특정 에러는 무시해도 된다는 경고까지 알려줘서 참 친절하다고 생각함)

 

2. 쿠버네티스가 뭔지 느낌 살리기

이전에 AWS 개발자 모임에서 무신사가 쿠버네티스 환경에서 Elasticsearch를 사용하는 ECK에 대한 강연을 간적이 있다.
 
아래는 해당 강연에 대해 무신사가 포스팅한 글이다.
https://medium.com/musinsa-tech/%EB%AC%B4%EC%8B%A0%EC%82%AC%EC%9D%98-%EC%97%98%EB%9D%BC%EC%8A%A4%ED%8B%B1%EC%84%9C%EC%B9%98-muse-musinsa-elasticsearch-e6355516186a

무신사의 엘라스틱서치 MusE (Musinsa Elasticsearch)

 
당시 쿠버네티스를 접해본 경험이 부족해서 내용을 모두 이해하지는 못했지만 인상 깊었던 키워드로는 Cluster, Pod, Node, .. 등이 있었다.
이들에 대해 산재된 정보를 보는 것 보다 kubectl를 사용해서 직접 Cluster를 프로비저닝 하며 만들어보니 이해가 빨랐다.
 
 

chap3.Orchestrating the Cloud with Kubernetes

Pods

Kubernetes의 핵심에는 포드가 있습니다.
포드는 1개 이상의 컨테이너가 포함된 모음을 나타냅니다. 일반적으로 상호 의존성이 높은 컨테이너가 여러 개 있으면 이를 하나의 포드에 패키징합니다.

이 예시에는 모놀리식 및 nginx 컨테이너가 포함된 포드가 있습니다.
포드에는 볼륨 또한 포함되어 있습니다. 볼륨은 포드가 존재하는 한 계속해서 존재하는 데이터 디스크이며 포드에 포함된 컨테이너에 의해 사용될 수 있습니다. 포드는 콘텐츠에 공유된 네임스페이스를 제공합니다. 즉, 이 예시의 포드 안에 있는 2개의 컨테이너는 서로 통신할 수 있으며 첨부된 볼륨도 공유합니다.
또한 포드는 네트워크 네임스페이스도 공유합니다. 즉, 포드는 IP 주소를 1개씩 갖고 있습니다.
이제 포드에 관해 더 자세히 살펴보겠습니다.
 
 

pods 만들기

포드는 포드 구성 파일을 사용하여 만들 수 있습니다. 모놀리식 포드 구성 파일을 살펴보겠습니다. 다음을 실행해 보세요.

cat pods/monolith.yaml

열린 구성 파일이 출력됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: monolith
  labels:
    app: monolith
spec:
  containers:
    - name: monolith
      image: kelseyhightower/monolith:1.0.0
      args:
        - "-http=0.0.0.0:80"
        - "-health=0.0.0.0:81"
        - "-secret=secret"
      ports:
        - name: http
          containerPort: 80
        - name: health
          containerPort: 81
      resources:
        limits:
          cpu: 0.2
          memory: "10Mi"

여기서 주목해야 할 부분이 몇 군데 있습니다. 다음과 같은 부분을 확인합니다.

• 포드가 1개의 컨테이너(모놀리식)로 구성되어 있습니다.
• 시작할 때 컨테이너로 몇 가지 인수가 전달됩니다.
• HTTP 트래픽용 포드 80이 개방됩니다.

kubectl을 사용하여 모놀리식 포드를 만듭니다.

kubectl create -f pods/monolith.yaml

포드를 살펴보세요. kubectl get pods 명령어를 사용하여 기본 네임스페이스에서 실행 중인 모든 포드를 나열합니다.

kubectl get pods

 

chap4. Kubernetes Engine을 사용하여 배포 관리

Task 3. Rolling update

배포는 순차적 업데이트 메커니즘을 통해 이미지를 새 버전으로 업데이트하도록 지원합니다. 배포가 새 버전으로 업데이트되면 새 ReplicaSet가 만들어지고, 이전 ReplicaSet의 복제본이 감소하면서 새 ReplicaSet의 복제본 수가 천천히 증가합니다.

 
 

Task 4. Canary deployments

프로덕션 환경에서 일부 사용자를 대상으로 새 배포를 테스트하려면 Canary 배포를 사용하세요. Canary 배포를 사용하면 작은 규모의 일부 사용자에게만 변경 사항을 릴리스하여 새로운 릴리스와 관련된 위험을 완화할 수 있습니다.
 

Create a canary deployment

Canary 배포는 새 버전의 별도 배포와 함께 기존 안정화 배포 및 Canary 배포를 동시에 대상으로 삼는 서비스로 구성됩니다.

 
먼저 새 버전의 새로운 Canary 배포를 만듭니다.

cat deployments/hello-canary.yaml

 

Output:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth
spec:
  replicas: 1
  selector:
    matchLabels:
      app: auth
  template:
    metadata:
      labels:
        app: auth
        track: stable
    spec:
      containers:
        - name: auth
          image: "kelseyhightower/auth:1.0.0"
          ports:
            - name: http
              containerPort: 80
            - name: health
              containerPort: 81
...

 

 

Task 5. Blue-green deployments

Rolling updates 순차적 업데이트는 최소한의 오버헤드, 최소한의 성능 영향, 최소한의 다운타임으로 애플리케이션을 배포할 수 있기 때문에 가장 좋은 업데이트 방식입니다. 그러나 배포를 모두 완료한 후에 부하 분산기를 수정하여 새 버전을 가리키도록 하는 것이 유리한 경우가 있습니다. 이 경우에는 Blue/Green 배포가 도움이 됩니다.
Kubernetes에서는 이전의 'blue' 버전용 배포와 새로운 'green' 버전용 배포를 만들어 업데이트할 수 있습니다. 'blue' 버전에 기존 hello 배포를 사용하면 라우터 역할을 하는 서비스를 통해 배포에 액세스하게 됩니다. 새 'green' 버전이 가동 및 실행되면 서비스를 업데이트하여 이 버전을 사용하도록 전환하게 됩니다.

 
1. 먼저 서비스를 업데이트합니다.

kubectl apply -f services/hello-blue.yaml

 

2. Green 배포를 만듭니다.

kubectl create -f deployments/hello-green.yaml

 

3. Green 배포가 있고 제대로 시작된 경우 현재 1.0.0 버전이 아직 사용되고 있는지 확인합니다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

 

4. 이제 서비스가 새 버전을 가리키도록 업데이트합니다. 

kubectl apply -f services/hello-green.yaml

 

5. 서비스가 업데이트되면 'green' 배포가 즉시 사용됩니다. 이제 항상 새 버전이 사용되고 있는지 확인할 수 있습니다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

 

 

3. 쿠버네티스로 무중단 배포 경험하기

사이드 프로젝트 구성 중 Jenkins를 이용한 무중단 배포를 사용하고 있었다. 추후 유지보수 중 서버가 내려가는 일이 발생하였는데 이때, 쿠버네티스를 이용하지 못해 nginx와 DNS 설정에 직면하였고, 이로 인해 무중단 배포를 실패한 적이 있었다.

이번 기회에 Jenkins로 직접 무중단 배포까지 경험했고, 이를 다른 프로젝트에도 적용해보며 배포에 대한 이해도를 높일 수 있었고 이는 이번 과정에서 가장 큰 성과라고 생각한다.



AWS만 주로 사용해보다가 구글 클라우드는 처음 사용해봤는데 이번 사용 경험으로 나중에 사용할 일이 있다면 선택지에 고려해 볼 수 있을 거 같다.
 
 

뱃지 획득!

 

Kubernetes in Google Cloud 뱃지와 함께 빵빠레를 빠밤~
 
 
더불어 수료하면 구글 모자까지 주니 일석이조로 좋은 경험이었다. (명예 구글러가 된 느낌 좋아요~)