2. 기본 오브젝트

데일리·2023년 10월 11일

쿠버네티스에 대해서

목록 보기

2/13

1. 기본 오브젝트 -Pod

1) Object - Container

Pod이란 쉽게 말하면 하나의 배포 단위라고 말할 수 있다. 이런 Pod에는 여러개의 컨테이너가 존재할 수 있는데 해당 컨테이너들은 하나의 host ip로 연결되어 있고 각각 고유의 port 번호로 구분이된 다는 것이 특징이다.

또 이런 ip들은 pod이 삭제될 때 삭제되고 재생성시에는 전혀 다른 ip가 생성이 되는 휘발적인 특징을 지니고 있고 이 ip는 외부에서는 접근이 불가하고 내부에서만 접근이 가능하다

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
spec:
  containers:
  - name: container1
    image: kubetm/p8000
    ports:
    - containerPort: 8000
  - name: container2
    image: kubetm/p8080
    ports:
    - containerPort: 8080

위의 코드는 pod를 생성하는 yaml파일이고 pod안에 2개의 컨테이너를 생성하는 것을 볼 수 있다.

해당 pod으로 접근하려는 cli는 아래와 같다
kubectl exec -ti {pod-name} /bin/bash

위와 같이 pod안에 컨테이너가 잘 뜨는 것을 볼 수 있다.

2) Object - Label

라벨의 목적은 각 오브젝트들을 사용의 목적에 따라 분류하기 위해서 사용한다.

예시를 보면 이해가 빠를 것이다. 위의 사진을 보면 type에 따라서 web, db 등으로 분류를 해놓았고 lo에 따라서 dev, prod 등으로 분류를 해놓았다. 이러한 분류를 바탕으로 서비스나 다른 오브젝트에서 분류된 pod들을 가지고 올 수 있다.

라벨은 위의 예시처럼 key: value로 이루어져 있고 모든 오브젝트에 하나 이상 적용이 가능하다


apiVersion: v1
kind: Pod
metadata:
  name: pod-2
  labels:
    type: web
    lo: dev
spec:
  containers:
  - name: container
    image: kubetm/init

apiVersion: v1
kind: Service
metadata:
  name: svc-1
spec:
  selector:
    type: web
  ports:
  - port: 8080

위의 코드는 각 pod안에 컨테이너들을 라벨링한 YAML코드이고 그 아래 코드는 type이 web만 pod을 연결하는 서비스를 생성하는 코드이다.

위와 같이 type이 web만 pod만 연결되는 서비스를 볼 수 있다.

3) Object - Node Schedule

Pod을 생성할 때 위의 그림처럼 노드를 직접 선택할 수도 있지만 memory와 limit만을 설정하면 노드 스케줄러가 자동으로 노드를 선택해준다.

만약 Memory가 초과시에는 pod을 강제 종료시키고 Cpu가 초과된다면 request를 낮출뿐 종료되지는 않는다.

2. 기본 오브젝트 - Service

1) Service - Cluster IP

서비스 생성시에 클러스터 ip가 자동으로 생성되는 방식이다. 서비스의 ip로 각 pod과 연결을 한다.

왜 굳이 pod ip도 있는데 서비스의 ip로 연결을 할까?

이는 pod의 ip가 휘발성을 띈다는 문제때문이다. 서비스의 ip는 따로 변경을 하지 않으면 변경이 되지 않지만 Pod ip는 pod의 메모리 초과로 강제 종료가 되버리면 Ip가 바뀌기 때문에 서비스 ip를 사용해 pod에 연결을 하고 pod이 삭제됬다 하더라도 라벨링으로 연결을 해놓으면 자동으로 pod은 서비스와 다시 연결이 되기 때문에 이런 방식을 사용한다.

서비스의 클러스터 ip도 외부에서는 접근이 불가하고 내부에서만 사용한다. 이러한 특징 때문에 cluster ip 방식은 운영자, 모니터링, 트래픽 관리 정도에서 주로 사용된다.

2) Node port

NodePort 방식은 cluster ip와 동일하지만 이 방식은 node에 동일한 ip가 주어지고 외부에서 접근이 가능하도록한 방식이다.

그렇지만 host ip는 외부에서 보안적으로 외부에서 접근을 하는 것이 좋지 않기 때문에 내부에서만 사용하는 것이 좋다

따라서 위의 방식은 보통 데모, 임시 연결에 사용되는 방식이다.

또 모든 노드에 동일한 Ip로 연결이 가기 때문에 특정 노드에서 연결이 가면 서비스에서는 다른 노드로 요청을 보낼 때가 있다. 이를 방지 해주는 것이 externalTrafficPolicy이다. 해당 설정을 local로 하면 요청을 보낸 노드에게로 서비스는 요청을 준다

apiVersion: v1
kind: Service
metadata:
  name: svc-2
spec:
  selector:
    app: pod
  ports:
  - port: 9000
    targetPort: 8080
    nodePort: 30000
  type: NodePort

위의 코드가 type이 NodePort인 서비스를 생성하는 코드이고 아래 사진 처럼 요청된 노드와 다르게 임의의 노드에서 응답이 오는 것을 볼 수 있다.

3) LoadBalancer

Node port와는 동일하지만 상위의 loadBalancer라는 객체가 존재한다. 이 로드밸런서는 자동으로 ip가 할당이 되는 것이 아니라 외부 ip지원툴에서 ip를 할당받아 설정해주어야 한다.

이 방식으로 host ip의 유출도 막을 수 있고 외부에서 접근또한 가능하기 때문에 주로 prod환경에서 사용하는 방식이다.

apiVersion: v1
kind: Service
metadata:
  name: svc-3
spec:
  selector:
    app: pod
  ports:
  - port: 9000
    targetPort: 8080
  type: LoadBalancer

위의 사진 처럼 로드 밸런서 타입의 서비스를 만들면 바로 생성이 되는 것이 아니라 아래의 사진처럼 pending 상태에 머무르는 것을 확인할 수 있다.

3. 기본 오브젝트 - Volumn

1) Volumn - emptyDir

해당 방식은 컨테이너들끼리 데이터를 공유하기 위해서 사용되는 방식이다. 해당 볼륨은 pod안에 생성되는 다는 것이 가장 큰 특징이다. 즉 pod이 삭제되면 볼륨도 삭제된다는 점을 주의해야한다.

생성 시에는 빈 데이터가 만들어지고 위의 그림의 코드처럼 mountPath를 통해 각 컨테이너들이 접근할 volumn을 지정할 수 있다.

2) Volumn - hostPath

Pod안이 아니라 Node안에 볼륨이 존재한다. 언뜻 보면 emptyDir보다 좋아보이고 주로 사용할 것 같지만 만일 Pod이 삭제되고 재생성될 때 해당 Node에 생성이 된다는 보장이 없기 때문에 이 방식도 주로 사용되지는 않는다.

물론 해당 각 노드가 생성될 때마다 pod에 대한 mount를 걸어주면 해결할 수 있지만 이는 번거롭기 때문에 사용하지는 않는다.

즉 이 방식은 Node 고유의 데이터를 주로 저장할 때 사용되고, 주의할 점은 pod이 생성될 때 Node에 경로가 있어야된다는 점이다.

apiVersion: v1
kind: Pod
metadata:
  name: pod-volume-3
spec:
  nodeSelector:
    kubernetes.io/hostname: minikube-m03
  containers:
  - name: container
    image: kubetm/init
    volumeMounts:
    - name: host-path
      mountPath: /mount1
  volumes:
  - name : host-path
    hostPath:
      path: /node-v
      type: DirectoryOrCreate

위 방식으로 볼륨을 생성할 수 있고 type: DirectoryOrCreate를 설정에 추가하면 nodePath가 없더라도 자동으로 생성해준다.

위의 사진 처럼 노드 안에 txt파일이 있는 것을 볼 수 있다.