[클라우드] 쿠버네티스

Letmegooutside·2022년 2월 7일
클라우드
0

클라우드 컴퓨팅

목록 보기
4/6

쿠버네티스

쿠버네티스란?

컨테이너 운영환경에서, 컨테이너들을 적절하게 관리하는 솔루션

예를 들어, 서비스 요청이 많아지는 경우 이에 대한 부하를 줄이기 위해 노드 수를 동적으로 늘리는 것과 같은 역할을 한다.
대표적으로 다음과 같은 역할을 한다.

  • 스케쥴링
    • 컨테이너 별 자원 최적화
    • 적절한 위치(클러스터 내 노드)에 배포
  • 정상/비정상 상태 체크 및 재기동
  • 컨테이너 리소스 모니터링
  • 컨테이너 동적으로 삭제 관리

이러한 일들을 자동화 해주는 솔루션이다.

장점

  • 애플리케이션 배포 단순화
  • 효율적인 하드웨어 활용
  • 자동 복구 및 모니터링
  • 오토 스케일링
  • 개발 환경 단순화

구조와 오브젝트

  • 클러스터 구조
    • 마스터 : 클러스터 전체를 관리하는 컨트롤러
    • 노드 : 컨테이너가 배포되는 머신 (가상머신, 물리적인 서버 머신)

  • 쿠버네티스 오브젝트
    오브젝트는 가장 기본적인 구성단위가 되는 기본 오브젝트와 이를 생성하고 관리하는 추가적인 기능을 가진 컨트롤러로 이루어진다.
    오브젝트들은 모두 오브젝트의 특성(설정 정보)을 기술한 오브젝트 스펙으로 정의가 되고, 커맨드 라인을 통해서 오브젝트 생성 시 인자로 전달하여 정의하거나, yaml이나 json파일로 스펙을 정의할 수 있다.
    예를 들면 다음과 같이 스펙을 정의한다.
     # pod_example.yaml
 apiVersion: v1
 kind: Pod
 metadata:
   name: nginx
 spec:
   containers:
   - name: nginx
     image: nginx:1.7.9
     ports:
     - containerPort: 8090
    kubectl create -f pod_example.yaml 로 오브젝트를 생성한다.

기본 오브젝트 종류

1. Pod

가장 기본적인 배포 단위로 컨테이너를 포함한다.

왜 여러 개의 컨테이너를 Pod 단위로 배포할까?
아래와 같은 특징 때문이다.

  • Pod 내의 컨테이너는 IP와 Port를 공유하여 서로 localhost로 통신이 가능하다.
  • Pod내에 배포된 컨테이너 간에는 디스크 볼륨 공유가 가능하다.

2. Volume

컨테이너가 재실행 될 때 마다 로컬 디스크는 Pod 설정에 따라서 새롭게 정의되어 배포되기 때문에 디스크에 기록된 내용이 유실된다.

컨테이너 재실행에 상관 없이 파일을 영속적으로 저장 해야 하는 경우 Volume이라는 스토리지를 사용한다.

컨테이너의 외부 디스크라고 볼 수 있으며 Pod가 기동할 때 컨테이너에 마운트해서 사용한다.

3. Service

같은 어플리케이션을 운용하는 Pod 간의 로드 밸런싱 역할을 한다.

또, 동적으로 생성되는 Pod 들의 동적 IP 와 달리 Service 는 지정된 IP 로 생성가능하다. (즉 Pod 접근은 어려운 반면, Service 접근은 더 쉽다)

다음과 같은 특징들이 있다.

  • 멀티 포트 지원
    웹 서버의 HTTP와 HTTPS 포트가 대표적인 예인데,  아래와 같이 ports 부분에 두 개의 포트 정보를 정의해주면 된다.
    apiVersion: v1
kind: Service
metadata:
	name: hello-node-svc
spec:
	selector:
		app: hello-node
	ports:
	- name: http
		port: 80
		protocol: TCP
		targetPort: 8080
	- name: https
		port: 443
		protocol: TCP
		targetPort: 8082
type: LoadBalancer
    80 → 8080 으로, 443 → 8082 로 가도록 한번에 설정할 수 있다.
  • 로드 밸런싱
    부하(트래픽)를 여러 Pod 으로 분산한다. (Pod 은 기본적으로 랜덤하게 선택된다)
  • Service Type
    서비스는 IP주소 할당 방식과 연동 서비스 등에 따라 크게 4가지로 구분된다.
    • Cluster IP
      디폴트 값으로 서비스에 클러스터 내부IP를 할당한다. 즉 클러스터 내부에서는 접근이 가능하지만 외부에서는 불가능하다.
    • Load Balancer
      외부 IP를 가지고 있는 로드밸런서를 할당하여 클러스터 외부에서 접근이 가능하다.
    • NodePort
      모든 노드의 IP와 포트를 통해서도 접근이 가능하게 된다. 예를 들어 아래와 같이 서비스를 NodePort 타입으로 선언을 하고, nodePort를 30036으로 설정하면, 아래 설정에 따라 클러스터 IP의  80포트로도 접근이 가능하지만, 모든 노드의 30036 포트로도 서비스를 접근할 수 있다.
      ...
type: NodePort
ports:
- name: http
	port: 80
	protocol: TCP
	targetPort: 8080
	nodePort: 30036
    • ExternalName
      외부 서비스를 쿠버네티스 내부에서 호출하고자 할 때 사용한다. 아래와 같이 서비스를 ExternalName 타입으로 설정하고, 주소를 DNS로  my.database.example.com으로 설정해주면 이 my-service는 들어오는 모든 요청을 my.database.example.com 으로 포워딩 해준다. (일종의 프록시와 같은 역할)
      kind: Service
apiVersion: v1
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com
  • headless 서비스
    서비스 디스커버리 솔루션을 제공하는 경우, 서비스의 IP 가 필요 없다.

    서비스 디스커버리 : 마이크로 서비스 아키텍처에서 기능 컴포넌트에 대한 엔드포인트(IP 주소)를 찾는 기능

    clusterIP: None 으로 주면 된다.
  • External IP
    서비스에 별도의 외부 IP를 지정해줄 수 있다.

4. Controller

Controller의 주 역할은 Pod 을 생성, 관리하는 것이다.

예를 들어 다음과 같이 yaml 포맷으로 정의할 수 있다.

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

종류는 다음과 같다.

  • ReplicationController (RC)
    지정된 숫자로 Pod를 기동 시키고 관리한다. selector, replicas, template 을 기본적으로 정의해야 한다.
    • selector : label 기준으로 어떤 Pod 들을 관리할지 정의한다.
    • replicas : 선택된 Pod 들을 몇 개의 인스턴스로 띄울지 정의한다.
    • template : Pod 을 추가로 기동할 때, 어떤 Pod 을 만들지 정의한다.
  • ReplicaSet
    ReplicationController 는 Equailty 기반 Selector를 사용하는 반면 ReplicaSet 는 Set 기반 Selector 를 사용한다.
  • Deployment
    ReplicationController 와 ReplicaSet 을 좀 더 추상화한 개념이다. 실제 배포할 때는 이 컨트롤러를 주로 사용한다.
  • DaemonSet
    Pod가 각각의 노드에서 하나씩만 돌게 한다. (균등하게 배포) 보통 서버 모니터링이나 로그 수집 용도로 사용하며 모든 노드가 아닌 특정 노드들만 선택할 수도 있다.
  • Job
    한번 실행되고 끝나는 Pod를 관리한다. Job 컨트롤러가 종료되면 Pod도 같이 종료한다.
  • CronJob
    주기적으로 돌아야하는(배치) Pod 을 관리한다. 별도의 schedule 을 정의해야 한다.
  • Stateful
    DB 와 같이 상태를 가지는 Pod 을 관리한다.

그 외 개념

  • 네임 스페이스
    한 클러스터 내에 논리적인 분리 단위이다.
    예를 들면 namespace:billing 과 namespace:commerce 는 같은 클러스터 내에 있지만 논리적으로 분리된 것이다.
    한 클러스터 자원을 가지고 개발 / 운영 / 테스트 3개의 네임 스페이스로 나눌 수 있다.
    네임 스페이스 별로 접근 권한, 리소스 할당량을 다르게 지정하여 운영할 수 있다.

    네임 스페이스는 논리적인 분리 단위이지, 물리적으로 환경을 분리(Isolation)한 것은 아니기 때문에 다른 네임 스페이스 간의 Pod라도 통신은 가능하다.

  • 라벨
    리소스를 선택하는데 사용된다.
    예를 들면 Pod 안에 다음과 같이 라벨을 달 수 있다.
    kind: Pod
...
metadata: labels: app: myapp
    selector 를 사용하여 리소스를 선택할 수 있다.
    예를 들어, Service 는 다음과 같이 Pod 을 선택할 수 있다.
    kind: Service
...
spec: selector: app: myapp

아키텍처

쿠버네티스 내부 구조는 크게 마스터와 노드 두 개의 컴포넌트로 분리될 수 있다.

1. 마스터

쿠버네티스 클러스터 전체를 컨트롤하는 시스템이다.

다음과 같이 구성되어 있다.

  • API 서버
    쿠버네티스는 모든 명령과 통신을 API를 통해서 하는데, 그 중심이 되는 서버가 API서버이다.
    쿠버네티스의 모든 기능들을 REST API로 제공하고 그에 대한 명령을 처리한다.
  • Etcd
    분산형 key-value 스토어로, 쿠버네티스 클러스터 상태나 설정 정보 저장하는 서버이다.
  • 스케쥴러
    Pod, Service 등 각 리소스를 적절한 노드에 할당하는 역할을 한다.
  • 컨트롤러 매니저
    컨트롤러들을 생산, 배포하며 이를 관리하는 역할을 한다.
  • DNS
    동적으로 생성되는 Pod, Service 등의 IP를 담는다.

2. 노드

마스터에 의해 명령을 받고 실제 서비스하는 컴포넌트다.
다음과 같이 구성되어 있다.

  • Kubelet
    노드에 배포되는 에이전트로, 마스터 API 서버와 통신하며 노드가 수행해야 할 명령을 받아서 수행하고, 노드의 상태 등을 마스터로 전달하는 역할을 한다.
  • Kube-proxy
    노드로 들어오는 네트워크 트래픽을 적절한 컨테이너로 라우팅한다.
    로드밸런싱 등 노드로 들어오고 나가는 네트워크 트래픽을 프록시하고, 노드와 마스터간의 네트워크 통신을 관리한다.
  • Container runtime
    컨테이너를 실행한다.
  • cAdvisor
    각 노드 내 모니터링 에이전트로 노드 내 컨테이너들의 상태, 성능 수집하여 마스터 API서버에 전달한다.
    이 데이터들은 주로 모니터링을 위해서 사용된다.



Reference
https://sungwookkang.com/1484
https://bcho.tistory.com/1256?category=731548
https://dailyheumsi.tistory.com/208

아 근데 무슨 말 인지 잘 모르겠음 여기 올린 포스팅 전부 완벽하게는 아니지만 어느정도는 이해하고 스스로 정리해서 올린건데 이건 일단 그냥 올림.. 뭘 모르겠는지도 모르겠고 ..뭔가 써봐야 알 것 같은 느낌 그냥 지금 드는 생각이라곤 .. 로고가 개 귀엽다 네이더스 생각나 도커가 좀 더 네이더스 같다 굿즈 만들어라 근데 난 안쓸래

profile
Letmegooutside
이전 포스트

[클라우드] 컨테이너

다음 포스트

[클라우드] 클라우드 컴퓨팅

0개의 댓글