[쿠버네티스 인 액션] 2. 도커와 쿠버네티스 첫걸음 (3)

2.3 쿠버네티스에 첫 번째 애플리케이션 실행하기

아래에서 소개하는 Replication controller를 통해 파드를 생성하는 방식은 이전 버전에서 사용하던 방식이며,
ReplicaSet을 구성하는 Deployment가 현재 권장하는 레플리케이션 설정 방법이다.

2.3.1 Node.js 애플리케이션 구동하기

• 애플리케이션을 배포하기 위한 가장 간단한 방법은 kubectl run 명령어를 사용해 JSON이나 YAML을 사용하지 않고 필요한 모든 구성요소를 생성하는 방법이다.
• 이전에 생성해 도커 허브에 푸시한 이미지를 실행해보자.

#kubectl run kubia --image=highlighter9/kubia --port=8080

• 책에서는 레플리케이션 컨트롤러를 생성하는 방식으로 위 명령어를 소개하고있지만 현재 deprecated된 상태이므로 아래 방식으로 생성해보자.
• 먼저 레플리케이션컨트롤러의 설정을 담은 yaml 파일을 생성한다.

$vi rc.yml

apiVersion: v1
kind: ReplicationController
metadata:
  name: kubia
spec:
  replicas: 1
  selector:
    app: web
    env: test
  template:
    metadata:
      labels:
        app: web
        env: test
    spec:
      containers:
        - name: kubia
          image: highlighter9/kubia
          ports:
          - containerPort: 8080

• 다음 명령어로 레플리케이션컨트롤러를 실행한다.

$kubectl apply -f rc.yml

파드소개

• 쿠버네티스는 개별 컨테이너들을 직접 다루지 않는다. 대신 함께 배치된 다수의 컨테이너라는 개념을 사용한다.
• 이 컨테이너 그룹을 파드(pod)라고 한다.
• 파드는 하나 이상의 밀접하게 연관된 컨테이너의 그룹으로 같은 워커 노드에서 같은 리눅스 네임스페이스로 함께 실행된다.
• 각 파드는 자체 IP, 호스트 이름, 프로세스 등이 있는 논리적으로 분리된 머신이다.
• 파드에서 실행중인 모든 컨테이너는 동일한 논리적인 머신에서 실행하는 것처럼 보이는 반면, 다른 파드에서 실행 중인 컨테이너는 같은 워커 노드에서 실행중이라 할지라도 다른 머신에서 실행 중인 것으로 나타단다.

파드 조회하기

• 컨테이너는 독립적인 쿠버네티스 오브젝트가 아니기 때문에 개별로 조회할 수 없다. 대신 파드를 조회해야 한다.

$kubectl get pods

• 파드의 STATUS가 Pending 상태라면 파드가 할당된 워커 노드가 아직 컨테이너 이미지를 다운로드 중이기 때문이다.
• 다운로드가 완료되었다면 STATUS가 Running 상태로 전환된다.
• 파드가 Pending 상태로 멈춰있다면 다음 사항을 확인해보자.
  1. 자체 이미지를 사용한다면 도커 허브에서 public으로 표시되어 있는지 확인한다.
  2. 이미지를 가져올 수 있는지 확인하기 위해 다른 머신에서 docker pull 명령으로 이미지 pulling을 시도한다.
• 파드에 대한 세부 정보는 다음 명령어로 확인할 수 있다.

$kubectl describet pod

백그라운드에서 일어난 동작 이해하기

• 위의 이미지는 쿠버네티스 내부에서 컨테이너 이미지를 가져오기 위해 수행하는 모든 단계를 보여준다.
• 로컬에 빌드한 이미지를 도커 데몬이 실행 중인 다른 워커노드에서 접근할 수 있게 하기위해 이미지를 빌드해 도커에 푸시한다.
•  kubectl 명령어를 실행하면 쿠버네티스의 API 서버로 REST HTTP 요청을 전달하고 클러스터에 새로운 레플리케이션컨트롤러 오브젝트를 생성한다.
• 레플리케이션컨트롤러는 새 파드를 생성하고 스케줄러에 의해 워커 노드 중 하나에 스케줄링된다.
  (스케줄링은 파드가 특정 노드에 할당됨을 의미한다.)
• 해당 워커 노드의 kubectl은 파드에 스케줄링됐다는 것을 보고 이미지가 로컬에 없기 때문에 도커에게 레지스트리에서 특정 이미지를 pull하도록 지시한다.
• 이미지를 다운로드한 후 도커는 컨테이너를 생성하고 실행한다.

---

2.3.2 웹 애플리케이션에 접근하기

• 각 파드는 자체 IP 주소를 가지고 있지만 클러스터 내부에 있으며 외부에서 접근이 불가능하다.
• 외부에서 접근하기 위해서는 Load Balancer 유형의 특별한 서비스를 생성해야 한다.
• 외부 로드 밸런서가 생성되면 로드 밸런서의 퍼블릭 IP를 통해 파드에 연결할 수 있다.

서비스 오브젝트 생성하기

• 서비스를 생성하기 위해 앞서 생성한 파드를 노출하도록 명령한다.

$kubectl expose rc kubia --type=LoadBalancer --name kubia-http

서비스 조회하기

• 다음 명령어로 새로 생성된 서비스 오브젝트를 볼 수 있다.

$kubectl get services

External IP를 이용해 서비스 접근하기

• 이제 서비스의 외부 IP와 포트를 통해 파드에 요청을 보낼 수 있다.

---

2.3.3 시스템의 논리적인 부분

레플리케이션컨트롤러, 파드, 서비스가 서로 동작하는 방식 이해

• 사용자는 컨테이너를 직접 생성하거나 동작시키지 않는다. 또한 파드도 직접 생성하지 않는다.
• kubectl run 명령을 수행하면 레플리케이션컨트롤러를 생성하고 레플리케이션컨트롤러가 실제 파드를 생성한다.
• 클러스터 외부에서 파드에 접근하기 위해서는 레플리케이션컨트롤러에 의해 관리되는 모든 파드를 단일 서비스로 노출하도록 명령한다.

파드와 컨테이너의 이해

• 예제에서 파드는 하나의 컨테이너를 가지고 있지만 원하는 만큼의 컨테이너를 포함시킬 수 있다.
• 컨테이너 내부에는 Node.js 프로세스가 있고 포트 8080에 바인딩돼 HTTP 요청을 기다리고 있다.
• 파드는 자체의 고유한 사설 IP 주소와 호스트 이름을 갖는다.

레플리케이션컨트롤러의 역할 이해

• 레플리케이션컨트롤러는 파드를 복제하고 항상 실행 상태로 만든다.
• 여기서는 파드의 레플리카를 지정하지 않았기 때문에 레플리케이션컨트롤러는 하나의 파드만 생성헀다.
• 어떤 이유로 파드가 사라진다면 레플리케이션 컨트롤러는 대체하기 위한 새로운 파드를 생성한다.

서비스가 필요한 이유

• 파드가 실행 중인 노드가 실패되거나 파드가 삭제되거나 비정상 노드에서 파드가 삭제되는 등 파드는 일시적이며 언제든 사라질 수 있다. 
• 이렇게 사라진 파드는 레플리케이션 컨트롤러에 의해 새로운 파드로 대체되고, 다른 IP 주소를 할당 받는다.
• 이것이 바로 서비스가 필요한 이유이다. 항상 변경되는 파드의 IP 주소 문제와 여러 개의 파드를 단일 IP와 포트의 쌍으로 노출시키는 문제를 해결한다.
• 서비스가 생성되면 정적 IP를 할당받고 서비스가 존속하는 동안 변경되지 않는다.
• 서비스는 동일한 서비스를 제공하는 하나 이상의 파드 그룹의 정적 위치를 나타내며, 서비스의 IP와 포트로 유입된 요청은 그 순간 서비스에 속해 있는 파드 중 하나에게 전달된다.

---

2.3.4 애플리케이션 수평 확장

• 파드는 레플리케이션컨트롤러에 의해 관리된다. kubectl get 명령어로 확인해보자.

$kubectl get replicationcontrollers

• DESIRED 열은 레플리케이션 컨트롤러가 유지해야할 파드의 레플리카 수, CURRENT 열은 현재 실행 중인 파드의 실제 수를 나타낸다.

의도하는 레플리카 수 늘리기

• 다음 명령어로 의도하는(desired) 레플리카 수를 변경할 수 있다.

$kubectl scale rc kubia --replicas=3

• 쿠버네티스에게 두 개의 파드를 추가도록 지시하는 대신, 원하는 인스턴스 수를 설정해 쿠버네티스가 원하는 상태를 달성하기 위해 어떤 액션을 취하는지 판단하도록 했다. 이것이 가장 기본적인 쿠버네티스의 원칙 중 하나이다.

스케일 아웃 결과 보기

• 실제 파드의 개수가 이미 세 개로 증가했으므로 파드의 조회 결과도 한 개가 아닌 세개로 표시된다.

• 애플리케이션 스케일링은 이와 같이 매우 간단하며, 확장이 필요할 때 언제든 명령어 하나로 인스턴스를 추가할 수 있다.
• 단, 애플리케이션 자체에서 수평 확장을 지원하도록 만들어야 한다는 것을 유념해야 한다.

서비스 호출 시 모든 파드가 요청을 받는지 확인

• 서비스가 다수의 파드 앞에서 로드 밸런서 역할을 해서 요청이 무작위로 다른 파드를 호출하고 있다.
• 파드가 클러스터 내에서 생성되고 삭제되며 IP가 변경되지만, 서비스는 항상 동일한 주소를 가지며 클라이언트와의 연결을 지원한다.

시스템의 새로운 상태 시각화

• 위 이미지는 시스템의 새로운 상태를 보여준다. 모든 파드 인스턴스가 레플리케이션 컨트롤러에 의해 관리되며, 서비스는 모든 파드에 요청을 전송한다.

---

2.3.5 애플리케이션이 실행 중인 노드 검사하기

• 파드가 스케줄링된 노드와 상관없이 컨테이너 내부에 실행 중인 모든 애플리케이션은 동일한 유형의 운영체제 환경을 갖는다.
• 각 파드는 자체 IP를 가지고 다른 파드가 같은 노드에 있는지 다른 노드에 있는지 상관없이 통신할 수 있으며, 각 파드는 요청된 만큼의 컴퓨팅 리소스를 제공받는다.

파드를 조회할 때 파드 IP와 실행 중인 노드 표시하기

• kubectl get pods 명령에서 파드가 스케줄링된 노드에 대한 정보가 보이지 않는 것은 중요하지 않은 정보이기 때문이다.
• 하지만 -o wide 옵션을 사용하면 추가 열을 요청할 수 있다.

$kubectl get pods -o wide

kubectl describe로 파드 세부 정보 살펴보기

---

2.3.6 쿠버네티스 대시보드 소개

GKE에서 쿠버네티스를 사용할 때 대시보드 접근하기

• GKE를 사용하는 경우 다음 명령어로 대시보드 URL을 찾을 수 있다.

#kubectl cluster-info | grep dashboard

 

• GKE 대시보드는 사용이 중단된 것 같다.
  https://cloud.google.com/kubernetes-engine/docs/concepts/dashboards?hl=ko

GKE 대시보드  |  Kubernetes Engine 문서  |  Google Cloud

• 대신 다음 경로를 통해 구글 클라우드 콘솔에서 제공하는 대시보드에 접근할 수 있다.
  https://console.cloud.google.com/kubernetes

---

Minikube를 사용할 때 대시보드 접근하기

$minikube dashboard

---

쿠버네티스 대시보드 배포 및 접근

 

아래 소개된 방식으로 대시보드를 배포 및 접근해보자.
https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/

Deploy and Access the Kubernetes Dashboard

• 연결에 성공하면 다음과 같은 화면으로 대시보드가 구성된다.