본문 바로가기

2.1 도커를 사용한 컨테이너 이미지 생성,실행,공유

쿠버네티스에서 구동되는 애플리케이션은 컨테이너 이미지로 패키징 되어야 한다. 도커이미지를 실행하면 일어나는 과정은 아래와 같다.

  1. docker run busybox echo "Hello World"
  2. 도커는 로컬 머신에 busybox 이미지가 저장되어 있는지 확인한다.
  3. 로컬에 이미지가 저장되어 있지않으면 도커 레지스트리로부터 이미지를 Pull받는다.
  4. 도커가 격리된 컨테이너에서 echo "Hello World"를 실행한다.

 

 

2.2 쿠버네티스 클러스터 설치

쿠버네티스 클러스터를 구축하는것은 매우 힘든일이다. 따라서 많은 cloud에서는 쿠버네티스를 구축할 수 있게 지원해주고 있고 로컬환경에서 테스트할때는 miniKube를 활용해볼 수 있다. 설치 및 기타 설정에 대한 내용은 과감하게 생략

 

 

 

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

2.3.3 The logical parts of your system

사실 실습코드들 대부분 그냥 따라서하면 문제없이 진행이 가능하다. 쿠버네티스를 이해하기 위해서는 쿠버네티스를 구성하는 여러가지 요소들의 개념을 이해하는것이 중요하기 때문에 Pod,Replication Controller,Service,Ingress의 개념을 알아보자.

Pod

  • 도커에서는 컨테이너 단위로 구분하는데 Pod는 한개 이상의 컨테이너의 그륩이다.
  • 쿠버네티스는 개별 컨테이너들을 직접 다루지 않고 함께 배치된 다수의 컨테이너를 묶어서 Pod라고 한다.
  • Pod 는 스토리지 및 네트워크를 공유한다. (Pod에 포함되는 모든 리소스들끼리는 localhost를 통해서 도달이 가능하다)
  • 밀접하게 결합된 하나 이상의 애플리케이션 컨테이너가 포함되는 단위이다.

 

Replication Controller

  • Replication Controller는 지정된 수의 파드 레플리카가 실행 중임을 보장하는 Object이다.
  • 즉, Replication Controller는 파드와 복제된 파드 셋이항상 기동되고 사용가능한지 확인한다.

파드가 너무 많으면 레플리케이션 컨트롤러가 추가적인 파드를 제거하고 너무 적으면 레플리케이션 컨트롤러는 파드를 새롭게 구동한다. 수동으로 생성하는 파드와 달리 레플리케이션 컨트롤러가 파드를 제어하면 파드는 실패하거나 삭제되거나 종료되는경우 자동으로 교체된다. 따라서, 단 1개의 파드만 구동하더라도 레플리케이션 컨트롤러르 사용하는것이 좋다.

아래와 같이 kubectl명령어를 통해 replication.yaml을 적용해보자. yaml에 작성된 replicas만큼 4개의 nginx pod가 구동된다.

 

kubectl apply -f replication.yaml

spec영역에 replication controller가 어떤 pod를 실행할지에 관한 스펙을 기술한다. spec의 하위에는 metadata가 있고 spec이 또다시 등장하는데 여기서 spec은 컨테이너에 대한 정보를 기입하는 spec이다.

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec: 
  replicas: 4
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

위에서 언급한내용처럼 spec에 서술한 replicas만큼 반드시 구동되고 있음을 보장하기 때문에replicationController는 pod의 재스캐줄링, 스케일링, 롤링업데이트에 사용할 수 있다.

 

Service

서비스 오브젝트는 파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법이다. 쿠버네티스 기본단위인 Pod는 ip가 랜덤하게 할당되고 Pod를 재생성할때마다 IP가 변하는 문제가있어서 endpoint로 지정하기 적절하지 않은 문제가 있다. 또한, 1개의 애플리케이션을 여러개의 Pod로 운영할때는 이를 묶는 작업이 필요한데 서비스가 이러한 역할을 한다.

  • Service는 지정된 IP로 생성이 가능
  • 여러 Pod를 묶어서 로드밸런싱 지원
  • 고유한 DNS이름을 가질 수 있다.

서비스는 ClusterIP, NodePort, LoadBalancer, ExternalName으로 구분할 수 있다.

 

 

  • ClusterIP
    • 기본 서비스 타입
    • 클러스터 내부의 노드나 포드에서 ClusterIP에 선언한 IP로 접속 가능하다.
    • 클러스터 외부에서 접근 불가능한 타입이다

 

apiVersion: v1
kind: Service
metadata:
    name: my-internal-service
spec:
    selector:
        app: my-app
    type: ClusterIP
    ports:
    - name: http
      port: 80
      targetPort: 80 
      protocol: TCP

 

 

  • NodePort
    • 각 노드의 지정된 포트를 할당하는 방식
    • node1: 8080, node2:8080 처럼 포트번호만 이용해서 접근할수 있게 해준다.
    • 외부에서도 접근이 가능

apiVersion: v1
kind: Service
metadata:
    name: my-nodeport-service
spec:
    selector:
        app: my-app
    type: NodePort
    ports:
    - name: http
      port: 80
      targetPort: 80
      nodePort: 30036
      protocol: TCP

 

 

  • LoadBalancer
    • GCP,AWS 서비스를 이용할때 사용가능한 옵션
    • 클라우드에서 제공해주는 로드밸런서와 연결되는 Service
    • 로드밸런서 IP를 이용해서 클러스터 외부에서 접근이 가능하게 해준다.

 

  • ExternalName
    • 클러스터 내부에서 외부로 접근할때 사용하고 외부로 접근하는 용도이므로 Selector가 필요 없음

댓글