[Kubernetes] 왜 K8S 인가

컨테이너란

허브 공간이 존재한다. 허브에는 수많은 컨테이너들이 존재한다. 빌드를 통해서 컨테이너에 푸시할 수 있다.

이 것을 사용하기 위해서 컨테이너를 pull 받아서 create 하고 start 하게 되면 컨테이너를 사용할 수 있게 된다.

컨테이너 VS 가상머신

가상 머신

해당 가상 머신 위에 올라가는 어플리케이션 성격에 따라 가상 머신은 미리 리소스를 할당해주게 된다. 그리고 특정 어플리케이션에 대해서 scale up 을 해줘야 하는 경우가 생긴다. 이런 경우에는 vertical 하게 scale up 하지 않고 horizontal하게 scale out을 해줘야 서버가 죽어도 나머지 서버로 돌릴 수가 있다.

컨테이너

컨테이너는 먼저, 도커가 host os에 올라가고, 도커의 컨테이너 어플리케이션이 올라가게 된다. 컨테이너에는 실제로 필요한 어플리케이션만 돌리면 되므로 확장성이 용이하다.(필요한 os까지 같이 확장할 필요 없이 어플리케이션만 확장하면 된다.)

그래서 주 목적은 deploy(배포)를 위해 만들어졌다. 그렇지만 각 컨테이너는 독립된 것 처럼 동작을 한다.

그럼 도커 플랫폼 자체가 망가지면 모든 컨테이너가 망가지게 된다. 즉, 하나의 시스템으로는 한계가 있다. 이를 위해 멀티호스트 도커 플랫폼을 만들어 줘야 한다.

아래와 같이 분산해서 띄어줄 수 있다.

혹시라도 하나의 도커 플랫폼이 죽더라도 다른 시스템은 살아 있으므로 괜찮다. 그렇지만, 이런 경우 각 도커 컨테이너 하나 하나를 엔지니어가 관리하는 것은 정말로 어려운 업무이다. 그래서 오케스트레이션이 필요한 것이다.

총괄 관리하는 control plane 을 두고 woker node를 관리하는 것이 컨테이너 오케스트레이션이다.

운영체제 위에 도커를 설치하고 그 위에 오케스트레이션을 설치 한다. 그 중 단연컨데 가장 유명한 것이 Kubernetes 이다.

그리스어로는 조타수라고 한다. 컨테이너를 실은 고래를 잘 운영해줘야 하는 중요한 역할을 하는 것이다. 구글이 만들었고 대규모 시스템 운영 경험을 녹아서 출시 발표 하였다. CNCF에서 만들었고 이 곳에서 쿠버네티스 자격증도 딸 수 있다.

쿠버가 필요한 이유 정리

모든 컨테이너를 각 서버별로 관리하기 힘들다.

• 개발자가 일일이 부하를 관리해주기는 어려운 일

여러 개의 도커 서버를 하나의 Pool로 사용할 수 있다.

• 쿠버네티스는 여러 개의 도커 데몬과 연결되어 있으며 사용자는 도커 데몬 서버가 몇개나 있는지 알 필요가 없다.
  • 알아서 여러 서버에 나누어 띄운다.
  • A, B, C 서버에 컨테이너를 분산해두면(이 분산 과정을 알아서 해준다.) → A 서버가 죽어도 B, C 서버에 있는 컨테이너들이 서비스를 계속 제공 가능
• 각각의 서버는 보통 Docker 데몬이 실행되고 있는 노드. (요즘은 containerd를 사용하는 경우도 많지만 개념은 같다)
• 사용자는 이 Pool 위에 단지 **“애플리케이션을 실행해줘”**라고만 요청하면 됩니다.
  • 실제로 어떤 서버에서 돌아가는지는 알 필요도, 신경 쓸 필요도 없다.
  • 쿠버네티스가 자동으로 적절한 노드를 골라서 컨테이너(Docker)를 배포해준다.
• 과거에는 사용자가 직접 도커 명령어(docker run, docker exec 등)를 실행하면서 어느 서버에 띄울지 고민했어야 했기 때문

서버 간 네트워크 통신을 가능하게 하는 CNI

• 각 서로 다른 서버에 있는 컨테이너는 기본적으로 서로 통신을 할 수 없다. (서버마다 서로 다른 프라이빗 IP를 가지기 때문이다.)
  • 보통의 서비스 시스템 구성 [클라이언트] ↓ [웹 서버 컨테이너 (A 서버에 있음)] ↓ [API 서버 컨테이너 (B 서버에 있음)] ↓ [DB 컨테이너 (C 서버에 있음)]서로 다른 서버(노드)에 띄어져 있어도 각 컨테이들이 서로 통신이 가능해야 한다.
• 💡 노드, 파드, 서버, 컨테이너
  • 노드(Node):
    • 노드는 쿠버네티스 클러스터 내에서 애플리케이션을 실제로 실행하는 서버입니다. 이는 물리적 서버일 수도 있고 가상 서버일 수도 있습니다. 노드는 쿠버네티스에서 애플리케이션을 실행하고, 네트워크와 스토리지 리소스를 제공합니다.
    • Kubelet이라는 에이전트가 노드 내부에서 실행되며, 쿠버네티스 마스터와 통신하고, Pod를 생성하거나 상태를 모니터링하는 등의 작업을 처리합니다.
  • Pod:
    • Pod는 쿠버네티스에서 관리하는 최소 실행 단위입니다. 하나의 Pod 안에는 하나 이상의 컨테이너가 포함될 수 있습니다. 각 Pod는 같은 네트워크 네임스페이스를 공유하고, 동일한 호스트에서 실행됩니다. 이는 여러 컨테이너가 같은 IP 주소와 포트를 공유할 수 있음을 의미합니다.
    • Pod 내부의 컨테이너들은 자원을 공유하고, 같은 호스트 내에서 실행되기 때문에, 하나의 Pod 내에서는 컨테이너들이 서로 쉽게 통신할 수 있습니다.
  • 하나의 노드에서 여러 Pod가 실행될 수 있음:
    • 한 노드에서 여러 Pod가 실행될 수 있습니다. 이때 각 Pod는 다른 컨테이너를 포함할 수 있으며, Pod들 간에 자원을 분리하고, 독립적으로 실행됩니다.
    • 쿠버네티스는 Pod들을 여러 노드에 분배하고, 리소스를 최적화하는 방식으로 스케줄링을 담당합니다. 따라서 노드 하나에 여러 Pod가 실행되지만, 필요에 따라 다른 노드에도 Pod를 배치하여 애플리케이션의 확장성과 가용성을 높입니다. </aside>
• 쿠버네티는 CNI(Container Network Interface)를 사용하여 모든 컨테이너가 동일한 네트워크 상에 있는 것처럼 동작하게 한다.
  • CNI는 여러 서버(노드) 간 Pod 네트워크를 하나로 묶어주는 기술
• 또한, kube-proxy를 통해 클러스터 내부의 네트워크 라우팅을 제어한다.
  • Service 요청을 받아서 적절한 Pod로 트래픽을 분산 전송
  • 외부에서 접근할 수 있는 IP/Port를 설정하고 내부 Pod로 연결