Kubernetes - Object

쿠버네티스 Object

서버 한 대는 마스터, 또 다른 서버는 Node로 구성되어있다.

하나의 쿠버네티스 클러스터의 구성

 

마스터는 쿠버네티스의 전반적인 기능들을 컨트롤하는 것

노드들은 자원을 제공하는 것

 

클러스터 전체 자원을 늘리고 싶다면 노드들을 계속 추가하면된다.

 

클러스터안에 Namespace가 쿠버네티스 오브젝트들은 독립 된 공간으로 만들어준다. 

네임스페이스에는 Pod들이 존재하고, Pod 들에게 외부로 부터 연결이 가능하게 해주는 Service(IP 할당)가 있어서 연결을 할 수 있다. 하지만 서로 다른 네임스페이스 간에는 연결 할 수 없다.

 

Pod

Pod 안에는 여러 컨테이너들이 존재한다

컨테이너는 한 개의 앱을 의미하므로 Pod는 여러 개의 앱을 들고 있다고 생각하면 됩니다.

 

Pod 에 문제가 생겨서 재생성이 되면 그 안에 데이터가 날라간다.

그래서 Volumn 만들어서 하드에 연결을 하면 Pod가 재생성되서 데이터가 삭제되는 걸 방지할 수 있다.

 

Pod 안에는 하나의 독립적인 서비스를 구동할 수 있는 컨테이너들이 있다.

Container들은 서비스가 연결될 수 있도록 포트를 가지고 있다.

한 개의 컨테이너가 여러개의 포트를 가질 순 있지만 같은 포트를 사용할 순 없다.

 

1 컨테이너에서 localhost:8080으로 호출할 수 있다.

Pod가 생성될 때 고유의 IP주소가 할당이되는데 쿠버네티스 클러스터 내에서만 이 IP를 통해서 Pod를 접근할 수 있다.

외부에서는 이 아이피로 접근할 수 없다.

 

그리고 만약 Pod 에 문제가 생기면 시스템이 감지하여 Pod를 삭제하고 재생성 하게 되는데

이 때 IP 주소는 변경이 된다. (휘발성)

Namespace

ResourceQuota / LimitRange 한 네임스페이스에서 사용할 수 있는 자원의 양을 한정 시킬 수 있다.
ex) CPU, HDD . . .

 

ConfigMap / Secret Pod 생성 시에 컨테이너 안에 환경변수 값을 넣던가 파일을 마운트 해주는 역할

 

Controller

Pod를 관리하는 역할

Replications Controller, ReplicaSet Pod가 죽으면 알아서 생성해준다는지 파드 개수를 줄이거나 늘릴 수 있다.

 

Deployment 배포 후에 Pod들을 새버전으로 업그레이드 해준다. 업그레이드를 하는 중에 문제가 생기면 Rollback을 쉽게할 수 있도록 도와준다.

 

DeamonSet Pod가 하나씩만 유지가 되도록 해준다. 이렇게 사용해야 될 모듈들이 있다.

 

CronJob 특정 작업만하고 종료를 시켜야 하는 일을 할 때 Pod가 그렇게 동작을 하도록 해준다.

이런 작업을 주기적으로 실행할 때 사용

 

Label

라벨은 Pod 뿐만 아니라 모든 Object 에 달 수 있다. Pod에 가장 많이 사용된다.

목적에 따라 오브젝트들을 분류하고, 따로 연결하기 위해서

한 Pod에는 여러개의 라벨을 달 수 있다. (Key: Value)

 

만약 웹 개발자가 데이터를 보고싶어한다면 type:web인 것들만 Service와 연결하여 보여주게 하면 된다.

그리고 Service 접속 정보를 웹 개발자에게 알려주면 된다.

원하는 Pod를 선택해서 사용하기 용이하다.

 

Service의 selector에 type을 지정하게 되면 해당 type의 Pod들을 연결하여 가져오게 된다.

 

Node Schedule

Pod는 결국 여러 Node들 중에 한 Node에 올라가야 한다.

1. 직접 선택하는 방법과 쿠버네티스가 선택하는 방법

1. Node에 라벨을 달고 Pod를 만들 때 Node를 지정할 수 있다.

2. 쿠버네티스의 스케쥴러가 판단

Node에는 전체 사용가능한 자원량이 있다. 

Node1 에는 1gb의 Memory가 남아있고, Node2 에는 3gb Memory가 남아져있다.

새로운 파드는 2gb의 Memory가 필요하고 쿠버네티스는 스케쥴러가 판단하여 Node를 지정한다.

limits: 최대 3Gi

Memory의 경우 limits가 넘어버리면 바로 Pod를 종료를 시킨다.

CPU의 경우에는 limits를 넘어버리면 request를 수치까지 낮추기는 하지만 Pod를 종료시키지 않는다.

 

CPU의 경우 파일을 복사하는데 A파일과 B파일이 동시에 복사를 진행한다고하면 속도가 느려지지 중단되지 않는다.

하지만 Memory의 경우 A 파일이 메모리를 다 차지하고있다고하면 B는 오류를 내뿜는다.

 

GCP 로 Master와 Node Server 2개 설정완료

 

Pod 생성

 

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

Service 없이 이 Pod 에 접근 할 수 있는 IP이고 쿠버네티스 클러스터 내에서만 호출 할 수 있다.

 

Master Console에서 명령어를 치는 것이 쿠버네티스 클러스터 내에서 명령을 작성하는거라고 생각하면 된다.

 

실습

1. yaml 명세 시에 한 개의 Pod 내에서 2개의 똑같은 포트번호를 가진 컨테이너를 생성할 때 생성이 되지 않는다.

2. ReplicaSet 컨트롤러를 명세하여 생성하였고, 대시보드에서 생성 된 Pod을 삭제하였다. 하지만 ReplicaSet의 역할로 인해 컨테이너는 삭제명령이 오자마자 다시 생성되었고, 생성 된 컨테이너는 IP가 변경되었다.

apiVersion: v1
kind: ReplicationController
metadata:
  name: replication-1
spec:
  replicas: 1
  selector:
    app: rc
  template:
    metadata:
      name: pod-1
      labels:
        app: rc
    spec:
      containers:
      - name: container
        image: kubetm/init

3. Label

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

위와 같이 Pod들을 3개 생성하였고, Labels 부분을 다르게 주었습니다.

이제 Service 를 만들어보겠습니다.

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

Service에 파드 부분을 보면 type이 web인 파드들을 포함하고 있는 것을 확인할 수 있습니다.

 

4. Node Schedule

apiVersion: v1
kind: Pod
metadata:
  name: pod-3
spec:
  nodeSelector:
    kubernetes.io/hostname: k8s-node1
  containers:
  - name: container
    image: kubetm/init

nodeSelector 로 Node의 레이블을 선택한다.

선택한 레이블의(노드에) Pod-3 가 생성된다.

 

5. 쿠버네티스 스케쥴러가 알아서 생성

apiVersion: v1
kind: Pod
metadata:
  name: pod-4
spec:
  containers:
  - name: container
    image: kubetm/init
    resources:
      requests:
        memory: 2Gi
      limits:
        memory: 3Gi

Node 1에는 용량이 부족하여 Node2에 자동으로 생성된다.

 

 

Service

Service는 기본적으로 자신의 Cluster IP를 가지고 있습니다.

이 서비스를 Pod에 연결 시켜두면 Service의 IP로도 Pod을 접근할 수 있다.

 

그런데 우리는 전 강의 때 Pod에도 똑같이 클러스터 내에서 접근할 수 있는 IP가 있는데

왜 Service를 통해 접근을 할까?

 

Pod 라는 존재는 시스템 장애건 성능 장애건 언제든지 죽을 수 있고, 재생성 된다는 것을 감안해야 한다.

재생성되면 IP가 변경되기 때문에 Pod의 IP는 신뢰성이 떨어진다.

 

하지만 Service는 사용자가 삭제하지 않는 이상 절대 삭제 될 일이 없습니다.

 

Service에는 여러가지 종류가 있고, 종류에 따라서 Pod에 접근을 도와주는 방식이 틀리다.

 

1. Cluster IP 방식

• 용도

  • 외부에서 접근할 수가 없고 클러스터 내에서만 사용하는 IP이다.
  • 이 IP에 접근할 수 있는 사람은 운영자와 같은 인가된 사람만이 접근할 수 있다.
  • 대시보드를 관리하거나 Pod의 상태를 모니터링할 때 사용한다.

외부에서 접근할 수가 없고 클러스터 내에서만 사용하는 IP

이 IP에 접근할 수 있는 사람은 운영자와 같은 인가된 사람이다.

대시보드를 관리하거나 Pod의 상태를 Debug할 때 사용

 

 

- 쿠버네티스 클러스터 내에서만 접근이 가능하다.

- Pod에 있는 IP와 특징이 똑같다.

- 외부에서는 접근할 수 없다.

- 여러 개의 Pod를 연결 시킬 수 있다.

- Service가 트래픽을 분산시켜 Pod에 전달한다.

ClusterIP는 생략이 가능하다. Default 이기 때문이다.

2. NodePort

용도

• 특징이 물리적인 호스트에 아이피를 통해서 Pod에 접근을 할 수 있다는 것인데 대부분 호스트IP는 보안적으로 내부망에서만 접근할 수 있게 구성하기 때문에 NodePort는 클러스터 밖에는 있지만 그래도 내부망 안에서 접근을 할 때 쓰인다.
• 일시적인 외부연동용으로도 사용이 된다. 내부 환경에서 시스템 개발을 하다가 외부에 간단한 데모를 보여줄 때 종종 네트워크 중계기에 포트포워딩에 해당 IP를 올려두고 OPEN 해 둘 수 있다.

- Service에는 기본적으로 ClusterIP 할당이 되어서 Cluster IP 타입과 비슷한 기능이 포함되어있다.

- 쿠버네티스 클러스터에 연결되어있는 모든 노드에게 똑같은 Port를 할당하여 외부로 부터 어느 노드건 간에 IP의 포트로 접속하면 이 서비스에 연결이 된다.

- Service는 자신에게 연결되어있는 Pod에게 트래픽을 전달해준다.

- 모든 Node에 Port가 만들어진다.

3. Load Balancer

용도

• 실제적으로 외부의 서비스를 노출시킬려면 Load Balancer를 이용해야 한다.
• 그래야 내부 IP가 노출되지않고 외부 IP를 이용해서 안정적으로 서비스를 배포할 수 있다.

기본적으로 앞에서 배운 NodePort의 성격을 그대로 가지고 있다.

추가적으로 각각의 Node에 트래픽을 분산시켜주는 역할을 한다.

Load Balancer에 접근하기 위한 IP주소는 기본적으로 생성되지 않고, 별도로 외부접속 IP를 할당해주는 플러그인이 설정이 되어있어야 IP가 생긴다.

AWS, Google의 경우 알아서 외부에서 접속할 수 있는 IP를 만들어준다.

그 IP를 통해서 외부에서 접속이 가능해진다.