쿠버네티스 개념 및 구성요소

서론

 

 AEWS 스터디 참가하면서 쿠버네티스에 대한 개념도 잘 기억이 안 나기도 하고 일요일에 참가 내용 복습 겸 쿠버네티스의 특징과 개념 및 구성요소에 대해 정리를 해보고자 한다. 

 

쿠버네티스란?? 

 

출처 : https://www.linux.co.kr/bbs/board.php?bo_table=lecture&wr_id=5821

 

 컨테이너 인프라 환경에서 컨테이너를 모니터링하고 제어하는 시스템 

 컨테이너를 하나만 관리한다면 모르겠지만 사용자들에게 서비스를 제공할 때 여러 서버들을 동시에 운영할텐데 엔지니어가 그 모든 컨테이너들을 다 명령어 치면서 관리하고 서버 다운되면 명령어로 다시 켜고 하는 것은 매우 매우 비효율적이기 때문에 쿠버네티스라는 시스템을 사용하여 서비스를 제공하게 된다. 

 

기능	내용
Auto Scaling	컨테이너 리소스를 모니터링 하여 바라는 상태를 유지
Self-Healing Infra	부하, 장애, 에러 등 대비 자가 복구
Apllication Life-Cycle Management	컨테이너 생성, 삭제, 수정 등 라이프 사이클 관리
Service Load Balancing	컨테이너 외부에서 내부로 들어오는 네트워크 요청에 대한 로드 밸런싱

출처 : https://blog.naver.com/love_tolty/222167051615

 

 

쿠버네티스 특징 

 1. 쿠버네티스가 바라보는 서버의 관점 

 

출처 : https://www.flaticon.com/kr/free-icon/livestock_3397536

 쿠버네티스에서는 서버 하나 하나를 그렇게 소중하게 대하지 않는다. 

 온프레미스 환경에서 서버를 구축하면 알겠지만 서버 구축시 os설정이나 네트워크 설정 등등 서버 하나 구축하고 요구사항에 맞게 설정하는데 시간이 진짜 많이 걸린다. 그래서 내 수고도 들어가 있고도 하니 애완동물처럼 애지중지하게 유지보수도 하고 꺼지지 않게 관리도 해주고 그런다. 하지만 쿠버네티스는 관점이 다르다. 

 서버 자체가 컨테이너이기 때문에 금방 다시 만들고 실행할 수 있으며 서버 세팅이나 의존성 세팅까지 되어 있는 상태로 바로 다시 실행할 수 있기 때문에 쿠버네티스에서 서버를 가축이라고 표현하기도 한다. 애완동물처럼 관심을 가지고 관리하는 게 아니라 필요하면 생성하고 도축하는 그런 느낌이다.  우리가 가축에게 이름을 부여하지 않듯 서버마다 이름으로 구별하지 않으며 그냥 워커 노드라고 칭한다.  

 또한 서버자체를 가축 취급하기 때문에 마스터 노드가 죽지만 않는다면 워커 노드1이 죽어도 그냥 2에 넘겨주거나 아님 바로 새로운 서버 만들어서 연결만 시켜주면 되는 거라 관리가 수월하다. 

 

 2. 바라는 상태 

 

 컨트롤러가 특정 리소스를 주기적으로 관찰하며 해당 리소스에 이상이 생기면 ( 컨테이너가 죽었다 등 ) 해당 문제를 해결하려고 한다. 

 쿠버네티스에서는 관리자가 원하는 상태를 세팅해주기만 하면 지속적으로 해당 상태가 유지되고 있는지 컨트롤러가 체크하며 관리자가 바라는 상태를 유지하려고 한다. ( 자동으로 죽은 컨테이너 재실행 등 )

 즉 우리가 지속적으로 모니터링하고 관리하지 않아도 웬만한거는 쿠버네티스가 알아서 설정한 바라는 값에 따라 고쳐준다. 

출처 : https://www.freepik.com/free-vector/datacenter-professional-workers-collection_10093855.htm#&position=1&from_view=search&track=ais&uuid=b0c4b5d1-44b0-4518-9070-6a1c0be0a393

 

  3. 네임스페이스와 클러스터 레벨 리소스 

 

   1) 네임스페이스 

    - 클러스터 내의 논리적인 분할

    - 네임스페이스마다 다른 권한 및 네트워크 정책을 설정할 수 있음 -> 논리적으로 그룹화하여 관리 가능 

    - 네임스페이스 a에서 사용하는 리소스를 네임스페이스b에서는 보이지 않는다. = 논리적 분할 

    - 하나의 클러스터를 여러 사용자나 팀 간 공유할 때 유용 

    - ex) Pod , Deployment, Service 등 대부분의 리소스 

default	kube-system	kube-public	kube-node-lease
기본적으로 할당 되는 네임스페이스	쿠버네티스  시스템에 의해 생성되는 API 오브젝트 관리용  관리자용 네임스페이스	클러스터 내 모든 사용자가 접근 가능한 오브젝트 관리용 네임스페이스	쿠버네티스 클러스터 내 노드 연결 정보 관리용 네임스페이스

 

 2) 클러스터 레벨 리소스 

  - 네임스페이스 영역과 상관없는 클러스터 레벨의 리소스  

  - ex) Node , PersistentVolume , StorageClass 등 

 

  4. 선언형 커맨드 

  - 사용자가 직접 시스템의 상태를 바꾸지 않고 사용자가 바라는 상태를 선언적으로 기술하여 명령을 내리는 방법  -> yaml파일로 정의 

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

 

 

쿠버네티스 구성 요소 

 

출처 : https://www.oss.kr/info_techtip/show/714d80e1-3977-4ca4-a223-69bd4d224987

 

 

마스터 노드 구성 요소 

 

 1) kube-apiserver 

  - 마스터 노드 중심에서 모든 클라이언트 및 컴포넌트로부터 오는 요청을 전부 받아내는 서버  -> 단순한 API서버임 

  - API 서버라서 명령어 날리면 해당 API서버인 kube-apiserver가 받아서 요청한 명령어에 대한 결과값을 사용자에게 날려준다. 

  - 단순하게 API서버이며 우리가 마스터노드에 파드 만들어 명령어 내리면 kube-apiserver가 받고 파드 만드는 명령어 수행하고 해당 결과를 리스폰스로 보내주는 그런 느낌으로 생각하면 될 듯? 

 

출처 : https://www.codestates.com/blog/content/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4

 

 2) etcd : 엣시디 

  - 쿠버네티스의 기반 스토리지이며 모든 메타 정보( key - value )를 저장하는 분산 저장소  ( ex_ 어떤 노드에 어떤 파드가 동작하는지 etcd에 저장됨 ) 

  - kubectl get pod 등의 명령어로 나오는 정보들은 전부 etcd로부터 받은 정보임 

  - 쿠버네티스 리소스에 대한 정보가 다 들어 있는 디비라고 생각하자 

 

 3) kube-scheduler 

 - 사용자 요청에 따라 적절하게 컨테이너를 워커 노드에 배치하는 스케줄러 

 - 여러 조건을 보고 파드에 부합한 노드를 선택해서 해당 노드에 파드 적재

 

출처 : https://m.blog.naver.com/alice_k106/221511412970

 

 

 4) kube-controller-manager 

 - 클러스터 내에 실행되는 여러 개의 컨트롤러를 통합 관리하는 프로세스 

 - 클러스터 내의 리소스 상태 감시하고 사용자가 바라는 상태로 유지하기 위한 동작을 수행 : 클러스터의 안전성 및 신뢰성 확보 

 - 다양한 컨트롤러를 통해 파드의 복제 , 롤링 업데이트, 상태 유지 등 기능을 수행 

 

 1] 레플리케이션 컨트롤러 

  - 사용자가 지정한 파드 복제 수 유지 

  - 파드가 삭제되거나 늘면 해당 설정한 수를 유지하기 위한 조치를 실행 

  - 가용성과 확장성을 보장 

 

 2] 레플리카셋 

  - 레플리케이션 컨트롤러보다 강한 넘 

  - 레이블 셀렉터를 사용하여 파드 그룹 관리 

  - 주로 디플로이먼트랑 같이 사용됨 

 

  3] 디플로이먼트 

   - 애플리케이션 롤링 업데이트 및 버전 관리 담당 

   - 새로운 버전 애플리케이션 배포 및 이전 버전 삭제 작업등 함 

 

   4] 스테이트풀셋

   - 순서대로 증가하는 고유 식별자를 가진 파드 그룹 관리 

 

 

워커 노드 구성 요소 

 

 1) kubelet 

  - 컨테이너 생성 및 삭제 등 상태를 모니터링하며 마스터 노드와 통신을 담당하는 연락책 

  - 컨테이너의 라이프 사이클을 관리 

  - 워커노드 파드 생성하기 위해 컨테이너 런타임에 명령을 하고 파드 상태를 모니터링 후 결과를 kube-apiserver에 전달 

 

 2) kube-proxy

  - 컨테이너의 네트워킹을 책임지는 프록시 , 네트워크 규칙을 유지 관리 

  - 모든 워커 노드마다 실행되는 네트워크 프록시 

  - 다른 pod간 네트워크 통신 및 클러스터 밖에서 pod로의 네트워크 통신을 관리 

출처 : https://www.alibabacloud.com/blog/from-confused-to-proficient-three-key-elements-and-implementation-of-kubernetes-cluster-service_595659

 

 

참고

 

 - 가시다님 자료 

 

https://velog.io/@pinion7/Kubernetes-%EB%A6%AC%EC%86%8C%EC%8A%A4-Namespace%EC%97%90-%EB%8C%80%ED%95%B4-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B3%A0-%EC%8B%A4%EC%8A%B5%ED%95%B4%EB%B3%B4%EA%B8%B0

Kubernetes 리소스 Namespace에 대해 이해하고 실습해보기

 

https://blog.naver.com/love_tolty/222167051615

쿠버네티스의 등장배경/구조 및 기능/동작원리 이해하기 - Analyzing the Background / Mechanism / Architectu

 

https://coffeewhale.com/apiserver

쿠버네티스 API서버는 정말 그냥 API서버라구욧

 

https://blog.frec.kr/cloud/etcd/

etcd에 대해 알아보자 | 쿲벖넶팂슶 Ep.2

 

https://m.blog.naver.com/alice_k106/221511412970

165. [Kubernetes] 쿠버네티스 스케줄러 및 스케줄링 동작 방식 (Taints, Toleration, Affinity, 커스텀 스케줄

 

https://velog.io/@gun_123/Kube-Controller-Manager

Kube Controller Manager

 

https://velog.io/@borab/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC-Concept

🐙 쿠버네티스 개념 정리 # 핵심 개념 🐚