[Study Jam] Orchestrating the Cloud with Kubernetes - 2

이번에는 Kubernetes Service에 대해 실습해보자

✔️ Service

한번 생성된 Pod는 영속적으로 존재하지 않을 수 있다.

동작 실패나 준비 상태 점검 등 여러 가지 이유로 인해 중단되거나 시작될 수 있으며 이로 인해 다음과 같은 문제가 발생한다.

Pod를 재가동하면 이전과는 다른 IP 주소를 가질텐데 그렇다면 Pods의 set와 통신하려면 어떻게 해야할까? 
이것이 서비스가 필요한 이유이다. 서비스는 Pods에 안정적인 Endpoint를 제공한다.

Google

Service는 labels을 사용해 어떤 Pods가 동작 중인지를 확인한다.

Pods에 올바른 라벨이 붙어있는 경우는 service에 의해 자동적으로 인식되어 공개된다. 

서비스가 일련의 Pod에 제공하는 액세스 레벨은 서비스의 타입에 달려있다. 

현재 서비스의 타입에는 세가지 유형이 있다. 

• ClusterIP(내부) - 기본 유형은 본 서비스가 클러스터 내에서만 표시됨을 의미한다.
• NodePort - 클러스터 내의 각 노드에서 외부에서 액세스 가능한 IP를 제공한다.
• LoadBalancer - 클라우드 제공자의 로드 밸런서를 추가해 서비스의 트래픽을 노드로 전달한다. 

 

✔️ Creating a Service

Service를 작성하기 전에, 먼저 https 트래픽을 처리할 수 있는 Secure pod를 만든다.

디렉토리를 변경한 경우 ~/orchest-with-kubernetes/kubernetes 디렉토리로 돌아가야 한다.

cd ~/orchestrate-with-kubernetes/kubernetes

다음의 monolith service 구성 파일을 살펴보자

cat pods/secure-monolith.yaml

kubectl create secret generic tls-certs --from-file tls/
kubectl create configmap nginx-proxy-conf --from-file nginx/proxy.conf
kubectl create -f pods/secure-monolith.yaml

이제 secure pod가 생겼고 secure-monolith pod를 외부로 노출시켜야 한다.

그렇게 하기 위해서는 Kubernetes Service를 만들어야 한다. 

다음의 monolith service 구성 파일을 살펴보자

cat services/monolith.yaml

kind: Service
apiVersion: v1
metadata:
  name: "monolith"
spec:
  selector:
    app: "monolith"
    secure: "enabled"
  ports:
    - protocol: "TCP"
      port: 443
      targetPort: 443
      nodePort: 31000
  type: NodePort

selector - app : "monolith" 와 secure : "enabled" 이라는 라벨이 붙은 pod를 자동으로 검색해 표시하는데에 사용한다. 

여기서 우리는 Nodeport를 공개해야 한다. 외부 트래픽을 포트 31000에서 nginx (포트 443)으로 전송할 수 있기 때문이다.

monolith service 구성 파일에서 monolith service를 작성하기 위해서는 kubectl 명령어를 사용한다.

kubectl create -f services/monolith.yaml

포트를 사용해 서비스를 노출하고 있다.

이것은 다른 앱이 우리의 서버 중 하나의 포트 31000에 바인드하려고 하면 포트 충돌이 발생할 가능성이 있다는 의미다.

보통 Kubernetes가 포트의 할당을 처리한다. 

지금 실습에서 나중에 헬스 체크를 더 쉽게 설정할 수 있도록 포트를 선택했다.

노출된 노드 포트의 모노리스 서비스에 대한 트래픽을 허용하려면 gcloud compute firewall-rules 명령을 사용한다.

gcloud compute firewall-rules create allow-monolith-nodeport \
  --allow=tcp:31000

이제 모든 것이 설정되었으므로 포트 포워딩을 사용하지 않고 클러스터 외부에서 secure-monolith service에 접근할 수 있다. 

첫번째로 노드 중 하나의 EXTERNAL IP 주소를 하나 가져온다.

gcloud compute instances list

curl을 사용해 secure-monolith service에 접근한다. 

curl -k https://<EXTERNAL_IP>:31000

Timed out 메세지가 뜬다 무엇이 잘못되었을까 ?

다음 명령을 사용해 원인이 무엇인지 생각해보자 

kubectl get services monolith
kubectl describe services monolith

Q1) 왜 모노리스 서비스로부터 응답을 받을 수 없을까 ?

Q2) 모노리스 서비스에는 몇개의 엔드포인트가 있을까 ?

Q3) 모노리스 서비스에서 pod를 골라야하는 레이블은 무엇인가 ?

모든 질문에 대한 정답은 Labels과 관련이 있다. 문제를 해결하기 위해 다음 섹션으로 넘어가보자

 

✔️ Adding Labels to Pods

지금은 모노리스 서비스에 엔드포인트가 없다. 

이런 문제를 트러블 슈팅하는 방법중의 하나는 라벨 쿼리와 함께 kubectl get pods 명령을 사용하는 것이다.

모노리스 라벨이 붙어있는 포드가 괘 많은 것을 확인할 수 있다.

kubectl get pods -l "app=monolith"

"app=monolith", "secure=enabled" 라벨로 찾아보고 싶다면

kubectl get pods -l "app=monolith,secure=enabled"

이 라벨 쿼리는 결과를 출력하지 않는다. "secure=enabled" 라벨을 추가해야 할 것 같다.
kubectl label 명령을 사용하여 누락된 secure= enabled 레이블을 secure-monolith Pod에 추가한다.

그 후 라벨이 갱신되었는지 확인할 수 있다.

kubectl label pods secure-monolith 'secure=enabled'
kubectl get pods secure-monolith --show-labels

 

이제부터 우리의 파드는 레이블되었고 모노리스 서비스의 엔드포인트 리스트를 확인할 수 있다.

kubectl describe services monolith | grep Endpoints

다시 한번 노드 중 하나에 접근해보는 것으로 테스트한다.

gcloud compute instances list
curl -k https://<EXTERNAL_IP>:31000

드디어 접속되었다 ! ! !

 

✔️ Deploying Applications with Kubernetes

이 실습의 목표는 생산 중인 컨테이너의 확장 및 관리에 대비하는 것이다. 

Depolyments를 사용하는 이유가 바로 이것인데 Deployments는 실행 중인 파드의 개수가 사용자가 지정한 원하는 파드의 수와 일치하도록 선언하는 방법이다. 

Deployments의 주요 이점은 포드 관리의 낮은 수준의 세부 사항을 추상화 하는 것에 있다. 

백그라운드에서 Deployments는 Replica Sets을 사용해 포드 시작 및 중지를 관리한다.

Pods를 업데이트 또는 확장해야 하는 경우 Deployment가 이를 처리한다. 

Deployment는 어떤 이유로 파드가 다운되었을 경우 팟의 재가동 또한 처리한다. 

 

간단한 예를 살펴보자

파드는 생성된 노드의 수명과 연결된다. 

위의 예시에서 Node3이 다운된 상태를 나타낸다. (Pod도 함께 다운된 것이다)

새 포트를 수동으로 만들고 해당 노드를 찾는 대신에 Deployment가 새 파드를 생성하고 Node2에서 시작했다.

 

❗ 자동으로 관리해준다는 것은 굉장히 편리하다.

 

이제 Pods와 Services에 대해 배운 내용을 토대로 Deployments를 통해 단일 어플리케이션을 소규모 서비스로 세분화 해보는 실습을 진행할 것이다.

 

✔️ Creating Deployments

이번 실습에서는 단일 앱을 3조각으로 나눈다. 각 역할을 다음과 같다.

• auth - 인증된 사용자의 JWT 토큰을 생성한다.
• hello - 인증된 사용자에게 인사한다.
• frontend - 트래픽을 auth 서비스와 hello 서비스로 라우팅한다. 

각 서비스에 대해 하나씩 deployments를 생성할 준비가 되엇다. 

그 후 auth 및 hello deployements용 내부 서비스와 fonrend deployments용 외부 서비스를 정의한다. 

 

완료되면 단일 서비스와 상호 작용하는 것과 유사하게 마이크로 서비스와 상호 작용할 수 있다. 

이제 각 부분을 독립적으로 확장 및 배포할 수 있게 된다. 

 

ahth deployment 구성 파일 예제를 확인한다.

cat deployments/auth.yaml

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

Deployment가 1개의 replica를 만들고 있으며 버전 20.0.0의 auth 컨테이너를 사용하고 있다.

kubectl 명령을 사용해 auth deployment를 작성하면 Deployment manifest의 데이터에 적합한 하나의 파드가 생성된다.

즉, Replicas 필드에 지정된 수를 변경해 파드 수를 조정할 수 있다. 

 

deployment object를 만든다.

kubectl create -f deployments/auth.yaml

이제 auth deployment를 위한 서비스를 생성해야 한다. 

kubectl create -f services/auth.yaml

이제 hello deployment에 대해서도 동일 작업을 진행한다.

kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yaml

frontend deployment도 진행한다.

kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf
kubectl create -f deployments/frontend.yaml
kubectl create -f services/frontend.yaml

컨테이너에 일부 구성 데이터를 저장해야 하므로 frontend를 작성하기 위해 한 단계가 더 있다.

frontend의 EXTERNAL IP를 찾아 상호작용 해야한다.

kubectl get services frontend

curl -k https://<EXTERNAL-IP>

hello 응답을 얻는다 !