Versions Compared

Version Old Version 12 New Version 13
Changes made by

Jack kim

Jack kim

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

K8s는 여러 컨테이너 런타임을 지원하며, 여기서는 Docker 런타임을 기본으로 설명한다.
(Docker 18.09 이상에서는 containerd를 Docker에서 기본으로 탑재한다)
그러므로, Docker에 대한 기본 개념 및 사용법을 알고 있다고 가정한다.

...

  • 지원하는 애플리케이션의 유형을 제약하지 않는다.

  • 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다.

  • 애플리케이션 레벨의 서비스를 제공하지 않는다.

  • 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 즉, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.

  • 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

...

  • kubelet

    • 클러스터의 각 노드에서 실행되는 에이전트.
      Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리.

    • Kubelet은 8s를 통해 생성되지 않는 컨테이너는 관리하지 않는다.

  • kube-proxy

    • kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부

    • kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.

    • kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.

  • Container runtime

...

  • DNS

    • 쿠버네티스에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함한다

  • 웹 UI (대시보드)

  • 컨테이너 리소스 모니터링

    • 컨테이너 리소스 모니터링은 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.

  • 클러스터-레벨 로깅

    • 클러스터-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.

Understanding Terms(중요)

Info

K8s에서 사용되는 용어 및 개념 이해는 아래 링크에 전체적으로 잘 나와있으므로, 참고 하도록 한다.

여기서는 위 블로그를 포함하여 각종 관련 사이트 및 K8s 공식 사이트 문서를 참고하여, 보다 간략히 k8s에 대한 이해에 반드시 필요한 개념 위주로 추려서 기술한다.
즉, 각각의 정책 오브젝트(pod, service, deployment, replica 등)마다 많은 기능과 옵션을 포함하기 때문에, deep dive한 설명은 생략될 수 있다.

아래 object들은 대부분 [yaml or json] 파일 형식으로 선언 및 정의하여, 사용 혹은 재 사용 된다.
상세한 명세는 k8s 공식 가이드를 참고할 수 있으며, 여기에서는 이후 별도로 다룰 예정이다.

참고로, 현재는 거의 모든 오픈소스 소프트웨어든 특정 벤더 소프트웨어든 간에, dockerfile, docker 이미지 및 k8s object 명세 파일을 각 제품의 배포(설치) 방식에 포함하고 있다.
따라서 대부분의 경우, 해당 소프트웨어의 k8s object 명세 파일을 받아서 사용 환경에 맞게 커스터마이즈하여 사용하게 된다.

Name Space

Pod

Pod 는 K8s에서 가장 기본적인 배포 단위로, 적어도 하나 이상의 컨테이너를 포함하는 단위이다.
다시 말해서, K8s는 컨테이너 하나하나의 단위로 관리하지 않고, 하나 이상의 컨테이너로 묶인 pod 단위로 관리한다.

여기서, Pod의 중요한 특징이 있는데,

  • Pod 단위로 internal IP가 할당된다.

  • Pod 안의 컨테이너들은 IP주소와 포트 공간을 공유한다. 즉, port만 다르다면 서로를 localhost 를 통해 통신할 수 있다.

  • 이들은 또한 SystemV 세마포어나, POSIX 공유 메모리와 같은 표준 프로세스 간 통신 방식으로 서로 통신할 수 있다.

  • Pod 내에 배포된 컨테이너 간에는 디스크 볼륨을 공유할 수 있다.
    따라서 아래 그림과 같이, Web server에 항상 부착되어야 할 프로그램을 묶어서 배포할 수 있으며,

  • 가장 일반적 시나리오는 웹(Nginx) 서비스하면서 access 로그를 pod volume에 남기고, 그 로그는 fluentd로 다시 수집하여 로그 분석 서버(ELK Stack 등)에 전송하는 경우가 있을 수 있다.

K8s는 위 특징을 활용하여, 반드시 같이 묶여서 배포되는 application을 하나의 단위로 관리할 수 있게 해준다.

...

참고로 Pod에 cpu, memory 사용에 대한 limit을 지정할 수 있으며, Linux CGroup(Control Group)을 사용하여 관리된다.

Job

Replication controller or Replica Set

Daemon set

Stateful Set

Service

Deployment

Secret

Service Account

Role & Cluster Role

Role Binding & Cluster Role Binding

Child Pages

Child pages (Children Display)

...