Gom3rye

Kubernetes 개념 본문

현대 오토에버 클라우드 스쿨

Kubernetes 개념

Gom3rye 2025. 6. 27. 17:46
728x90
반응형

Container Runtime

  • 일반적인 가상화 환경은 하드웨어 수준에서 가상화되지만 Container는 운영체제 수준에서 가상화를 수행한다.
  • Container는 운영체제의 커널을 공유하기 때문에 상대적으로 가볍고 유연하게 운영이 가능하다.
  • Container화 된 애플리케이션은 빠르게 실행되며 가상 머신과 비교했을 때 자원을 더 적게 사용해서 하나의 시스템에서 더 많은 애플리케이션을 구동할 수 있다.
  • 운영체제를 공유해서 사용하기 때문에 패치, 업데이트 등 유지 관리와 관련한 오버헤드가 줄어든다.
  • 빠르게 변화하는 비즈니스 환경에서는 Container가 애플리케이션 배포의 최적의 솔루션이라고 할 수 있다.
  • Runtime은 프로그래밍 언어가 구동되는 환경을 의미하는데 자바스크립트가 브라우저에서 실행되면 런타임은 브라우저
  • Container를 생성하고 실행할 수 있도록 도와주는 것이 Container Runtime이다.

종류

Containerd

  • Docker 사에서 개발한 오픈 소스 런타임
  • Container 이미지를 내려받고 압축을 푸는 과정부터 Container를 실행하고 감독하는 과정까지 Container의 전체 수명 주기를 관리하는 기능을 제공한다.

Docker

  • Containerd 위에 설치하는 데몬
  • Container를 생성하고 관리하는데 필요한 모든 기능을 제공한다.

CRI-O

  • RedHat, Intel, SUSE, Hyper, IBM 등의 관리자 및 커뮤니티를 중심으로 개발된 오픈 소스 런타임
  • 도커를 대체하기 위한 툴로 개발

Container 런타임으로 가장 많이 사용하는 것이 Docker이지만 Kubernetes에서 도커를 더 이상 지원하지 않겠다고 발표하면서 크라이오 런타임의 인기가 높아지고 있다.

Container Orchestration

다수의 Container를 유기적으로 연결 및 실행할 뿐 아니라 상태를 추적하고 보존하는 등 Container를 안정적으로 사용할 수 있게 만들어주는 것

  • Container를 효과적으로 관리하는 것이 목적이다.
  • 여러 시스템에 Container를 분산해서 배치하거나 문제가 생긴 Container를 교체하는 등 여러 역할을 수행한다.
  • 종류
    • Docker Swarm
      • 간단하게 설치할 수 있고 사용하기도 용이하다.
      • 기능이 다양하지는 않아서 대규모 환경에 적용하려면 사용자 환경을 변경해야 할 수 있기 때문에 소규모 환경에서는 유용하지만 대규모 환경에서는 잘 사용하지 않는다.
    • Mesos
      • Apache의 오픈 소스 프로젝트로 트위터, AirBnB, Apple, Uber 등 다양한 곳에서 이미 검증된 솔루션이다.
      • 2016년 DC/OS(Data Center OS, 대규모 서버 환경에서 자원을 유연하게 공유할 수 있도록 해주는 도구)의 지원으로 매우 간결하지만 기능을 충분히 활용하려면 분산 관리 시스템과 연동을 해야 하기 때문에 여러 가지 솔루션을 유기적으로 구성해야 하는 부담이 있다.
    • Nomad
      • Vagrant를 만든 Hash Corp 사의 도구로 Vagrant처럼 간단한 구성으로 Orchestration 환경을 제공한다.
      • Docker Swarm과 마찬가지로 기능이 부족하므로 복잡하게 여러 기능을 사용하는 환경이 아닌 가볍고 간단한 기능만 필요한 환경에서 사용하기를 권장한다.
      • Hashi Corp의 Consul(서비스 검색, 구성, 분할 기능 제공)과 Valut(암호화 저장소)와의 연동이 원활하므로 이런 도구에 대한 사용 성숙도가 높은 조직이라면 도입을 고려해볼 수 있다.
    • Kubernetes
      • 다른 오케스트레이션 솔루션보다는 초기 진입 장벽이 높지만 쉽게 사용할 수 있도록 도와주는 도구들이 있어서 점점 설치가 쉬워지는 추세이다.
      • 다양한 형태의 Kubernetes 위에서 동작할 수 있게 한다.
      • 현재는 거의 모든 벤더와 오픈 소스 진영 모두에서 Kubernetes를 지원하고 그에 맞게 통합 개발되고 있다.

Kubernetes

Container 기반의 애플리케이션을 개발하고 배포할 수 있도록 설계된 오픈 소스 플랫폼

  • 대규모 시스템을 개발하는 프로그래머가 대규모 서버군을 직접 관리하는 일이 드물듯이 일반적인 개발자가 k8s를 사용할 일도 거의 없다. → 일반적인 개발자가 잘 다루지는 않는다.
  • k8s에 대한 지식은 시스템을 개발할 때 유용할 수 있는데 k8s로 관리되는 시스템은 이를 전제로 개발되어야 하고 그렇지 않다면 k8s의 이점을 제대로 살릴 수 없기 때문에 프로젝트 매니저나 시스템 엔지니어를 담당하는 사람도 k8s로 어떤 일을 할 수 있는가를 잘 이해해야 한다.
  • k8s는 여러 대의 물리적 서버에 걸쳐 실행하는 것을 전제로 한다.
    • 물리적 서버 한 대 한 대 마다 제각기 여러 개의 Container를 실행한다고 가정한다.
    • 여러 대의 서버에서 일일이 Container를 실행하고 관리하기는 쉬운 일이 아닌데 k8s는 이를 위한 도구이다.
    • Docker compose를 쓴다고 해도 물리적 서버가 여러 대라면 반복 작업은 사라지지 않고 어떻게든 Container를 생성해 실행했다 하더라도 일일이 모니터링하며 장애가 발생하면 Container를 다시 실행해야 하는 것은 물론이고 Container를 업데이트하려면 다시 한 번 큰 수고가 따른다.
    • 번거로운 Containerㄹ 생성이나 관리의 수고를 덜어주는 도구로 도커 컴포즈에서 사용되는 컴포즈 파일과 비슷한 정의 파일만 작성하면 이 정의에 따라 모든 물리적 서버에 Container를 생성하고 생성한 Container를 관리해준다.

Kubernetes의 특징

  • 무중단 서비스
    • 서비스 중단 없이 애플리케이션을 업그레이드 할 수 있어서 안정적으로 서비스를 제공할 수 있다.
  • 클라우드 벤더 종속성 해결
    • 대다수의 클라우드 벤더에서 쿠버네티스를 지원한다.
  • 효율적인 자원 사용
    • K8s는 Pod가 사용할 수 있는 자원(CPU, Memory)을 사전에 지정할 수 있어서 시스템의 전체 자원을 효율적으로 사용할 수 있다.
  • 유연한 확장성
    • Pod의 자원 사용률에 따라 Pod의 개수를 늘리거나 줄일 수 있어서 CPU 사용률이 200%로 증가하면 Pod를 1개에서 5개로 늘리고 CPU 사용률이 감소하면 Pod를 다시 1개로 줄일 수 있다.
  • 항상 바람직한 상태를 유지한다.
    • K8s도 컨테이너를 생성하거나 삭제할 수 있지만 일일이 명령어를 입력하는 방식을 권장하지 않는다.
    • Container는 00개, 볼륨은 nn개로 구성하라. 와 같이 어떤 바람직한 상태를 yaml 파일에 정의하고 자동으로 컨테이너를 생성하거나 삭제하면서 이 상태를 만들고 유지하는 것이 K8s의 기본적인 아이디어이다.
    • Docker Compse는 옵션을 지정해 수동으로 Container의 수를 바꿀 수는 있어도 모니터링 기능이 없어서 컨테이너를 만들 때 관여하지 않지만 이에 반해서 K8s는 이 상태를 유지하는 기능이 있다.
    • 하나의 Container가 망가지면 k8s가 알아서 망가진 Container를 삭제하고 새 Container로 대체하며 정의해서 Container 5개를 4개로 수정하고 Container 1개를 삭제한다.

Kubernetes의 리소스

  • 워크로드 API 리소스: 컨테이너 실행에 관련된 리소스
    • Pod
    • ReplicationController
    • ReplicaSet
    • Deployment
    • DaemonSet
    • StatefulSet
    • Job
    • CronJob
  • 서비스 API 카테고리: 컨테이너를 외부에 공개하는 엔드 포인트를 제공하는 리소스
    • ClusterIP
    • ExternalIP
    • NodePort
    • LoadBalancer __> 여기까지 Ingress와 연관ㅇ
    • Headless
    • ExternalName
    • None-Selector
    • Ingress
  • Config & Storage API: 설정/기밀 정보/영구 볼륨 등에 관련된 리소스
    • Secret
    • ConfigMap
    • PersistentVolumeClaim
  • 클러스터 API: 보안이나 쿼터 등에 관련된 노드
    • Node
    • Namespace —> 실제로 우리가 쓰는 건 여기 2개 정도
    • PersistentVolume
    • ResourceQuota
    • ServiceAccount
    • Role
    • ClusterRole
    • RoleBinding
    • ClusterRoleBinding
  • Meta Data API: 클러스터 내부의 다른 리소스를 관리하기 위한 리소스
    • LimitRange
    • HorizontalPodAutoScaler
    • CustomResourceDefinition

Kubernetes Architecture

  • Pod
    • 쿠버네티스에서 생성할 수 있는 가장 작은 배포 단위이이면서 단일 혹은 다수의 Container를 포함한다.
    • Pod 이외에 Service, Volume, Namespace 등을 묶어서 Object라고 하고 이 Object는 쿠버네티스에서 상태 관리가 필요한 대상이다.
    • Pod 와 Container의 차이
      • 쿠버네티스는 Container를 개별적으로 하나씩 배포하는 것이 아니라 유사한 역할을 하는 Container를 Pod라는 단위로 묶어서 배포한다.
      • 쇼핑몰 웹 사이트에서는 사용자가 상품을 검색하고 주문하는 애플리케이션과 상품 정보 및 이미지를 저장하는 저장소가 있는데 이 둘은 서로 유기적인 관계를 맺고 있기 때문에 애플리케이션과 저장소는 별도의 Container이지만 쇼핑몰 웹 사이트 용도의 Pod 하나로 묶어서 배포할 수 있다.
  • 쿠버네티스 구조
    • Kubernetes Cluster
      • 여러 리소스를 관리하기 위한 집합체로 Master Node와 Worker Node를 이용해서 Kubernetes Cluster를 구성한다.
    • Node
      • 쿠버네티스 리소스 중에서 가장 큰 개념
      • 쿠버네티스 클러스터의 관리 대상으로 등록된 Container가 배치되는 대상이다.
      • 쿠버네티스 클러스터 전체를 관리하는 서버인 마스터가 항상 하나 이상은 있어야 한다.
      • Master Node를 Control Plain이라고 하기도 하는데 API Server나 스케쥴러, 컨트롤러 매니저 등이 배치되고 워커 노드에서는 kubelet, 프록시, 컨테이너 런타임이 배치된다.
      • Master Node에는 kubectl을 설치해야 한다.
        • persistent storage: pod는 휘발성이므로 worker node에 존재하는 pod가 삭제되면 pod 안의 모든 데이터도 삭제되기 때문에 중요한 데이터는 pod 외부에 있는 저장소에 저장해 두어야 하는데 CSI(Container Storage Interface)로 외부 저장소를 Pod에 연결할 수 있다.
  • Kubernetes의 Component
    • Master Node에는 Cluster를 유지하고 제어하기 위한 다양한 Component들이 있고 Worker Node에는 애플리케이션을 실행하기 위한 Component 들이 있다.
      • Master Node: etcd, API Server, Controller Manager, Scheduler
      • Worker Node: Proxy, kubelet, Container Runtime
    • API Server는 Kubernetes Cluster의 API를 사용할 수 있게 해주는 프로세스
      • Cluster로 요청이 왔을 때 그 요청이 유효한지 검증해준다.
      • 검증 과정
        • 사용자 인증 → 명령 수행(kubectl create -f deployment.yaml) → Master Node의 API Server가 이 명령이 유효한지 확인하고 워커 노드의 Kubelet에게 전달해서 명령을 수행한다.
    • etcd는 Cluster에 필요한 Pod와 같은 리소스들의 상태 정보가 저장되는 곳이다.
      • API Server는 Pod를 만든다는 사실을 etcd에 알려서 상태를 저장하고 사용자에게 pod가 생성되었음을 알린다.
      • 이 정보들은 key-value 형태로 저장되는데 사용자에게 Pod가 생성되었음을 알렸지만 내부적으로는 여전히 Pod가 생성되지 않았다.
    • Scheduler
      • Pod를 위치시킬 적당한 Worker Node를 확인하고 API Server에 이 사실을 알리는데 API Server는 etcd에 해당 정보를 저장한다.
      • Pod를 어디에 배치해야 할 지는 Worker Node의 리소스 사용량(CPU나 메모리 등의 사용량)을 참조해 결정한다.
    • Kubelet
      • API Server로부터 Pod의 생성 정보를 전달 받아서 Pod를 생성하는 컴포넌트
      • kubelet은 Cluster의 각 노드에서 실행되는 에이전트로 Pod에서 Container의 동작을 관리한다.
      • kubelet은 Pod를 생성했다면 API Server에 생성된 Pod의 정보를 전달하고 API Server는 etcd를 수정해서 최종적으로 어떤 Worker Node에 어떤 Pod가 생성되었는지 etcd에 저장한다.
    • Controller Manager
      • kube-controller-manager와 cloud-controller-manager 2가지 유형이 있다.
      • kube-controller-manager는 다양한 Component의 상태를 지속적으로 모니터링하는 동시에 실행 상태를 유지하는 역할을 하는데 Controller Manager가 특정 Worker Node와 통신이 불가능하다고 판단되면 해당 Node에 할당된 Pod를 제거하고 다른 Worker Node에서 Pod를 생성해 서비스가 계속되도록 한다.
      • cloud-controller-manager는 EKS, AKS와 같은 Public Cloud에서 제공하는 Kubernetes와 연동되는 서비스들을 관리한다.
    • Proxy
      • kube-proxy는 Cluster의 모든 노드에서 실행되는 Network의 Proxy
      • Proxy는 노드에 대한 Network의 규칙을 관리하기 때문에 Cluster 내부와 외부에 대한 통신을 담당한다.
      • 실제로 내가 요청하는 것과 실제로 행하는 것은 다르다. → 프록시
      • 자바 스크립이 브라우저를 못 벗어나는 거지 다른 언어들은 브라우저를 벗어날 수 있다.
    • Container Runtime 이 있어야 컨테이너를 만들어서 구동을 시키던가 뭘 할 수 있다.

api → data, interface의 2가지 의미

면접때 → etcd, ingress controller에 대해서 많이 물어본다.

Kubernetes Controller

Pod를 관리하는 역할

  • 쿠버네티스에서 제공하는 Controller
    • DaemonSet, Deployment, ReplicaSet, StatefulSet, Job, CronJob, Replication Controller

                                         Deployment                                                     CronJob

DaemonSet ReplicaSet StatefulSet Job ReplicationController
  • ReplicaSet: 몇 개의 Pod를 유지할지 결정하는 Controller
    • apiVersion: apps/v1
    • kind: ReplicaSet
    • ReplicaSet이 관리하는 동일한 구성의 Pod를 Replica라고 부른다.
    • Pod의 수를 조정하는 것을 Replica의 수(동일한 구성의 pod, 동일한 container의 pod)를 조정한다고 하거나 결정한다고 표현한다.
  • Deployment
    • Kubernetes에서 stateless(상태없는 - 저장하지 않는) 애플리케이션을 배포할 때 사용하는 기본적인 Controller
    • ReplicaSet의 상위 개념이면서 Pod를 배포할 때 사용하고 다양한 방법을 지원해서 배포할 때 세밀한 조작이 가능하다.
    • apiVersion: apps/v1
    • kind: Deployment
  • DaemonSet
    • Pod를 생성하고 관리하는 Controller
    • DockerSwarm의 global과 같은 개념
    • 모든 Node에 Pod를 배포하고 관리하는 Controller
    • DaemonSet은 대부분 Node마다 배치되어야 하는 성능 수집 및 로그 수집 같은 작업에 사용된다.
  • taint와 toleration
    • 쿠버네티스 클러스터를 운영하다보면 특정 Worker Node에 있는 특정 성격의 Pod에게만 배포하고 싶을 때가 있다. (누구에겐 배포하고 누구에겐 배포하지 않는 것)
    • ex. GPU가 설치된 Worker Node에 GPU가 필요한 Pod만 배포하고 싶은 경우에 taint와 toleration 사용
    • taint가 설정된 노드에는 일반적으로 사용되는 pod는 배포할 수 없으나 toleration을 적용하면 배포할 수 있다.
  • StatefulSet
    • 애플리케이션의 Stateful을 관리하는데 사용하는 워크로드 API 오브젝트
    • Pod 집합의 Deployment와 Scaling을 관리하며 Pod들의 순서 및 고유성을 보장한다.
    • Deployment와 유사하게 동일한 Container 스펙을 기반으로 둔 Pod들을 관리한다.
    • Deployment와 다르게 StatefulSet은 각 Pod의 독자성을 유지하는데 이 Pod들은 동일한 스펙으로 생성되었지만 서로 교체는 불가능하다.
    • 각각은 재 스케쥴링 간에도 지속적으로 유지되는 식별자를 가진다. → Storage Volume을 사용해서 워크로드에 지속성을 제공하려는 경우 솔루션의 일부로 StatefulSet을 사용할 수 있다. (지속성을 유지하고자 할 때 사용)
  • Job
    • 하나 이상의 Pod를 지정하고 지정된 수의 Pod가 성공적으로 실행되도록 해주는 Controller
    • 노드의 하드웨어 장애나 재부팅 등으로 Pod가 비정상적으로 작동하면 다른 노드에서 Pod를 시작해서 서비스가 지속되도록 해준다.
  • CronJob
    • Job의 일종으로 특정 시간에 특정 Pod를 실행시키는 것과 같이 지정한 일정에 따라서 Job을 실행시킬 때 사용한다.
    • 애플리케이션 프로그램, 데이터베이스 등에서 데이터를 백업하는데 주로 사용한다.
    • apiVersion: batch/v1
    • kind: CronJob
    • Spec:
          schedule: */1 * * * *

Kubernetes Service

  • Pod는 Kubernetes Cloud 안에서 옮겨 다니는 특성이 있는데 Pod가 실행 중인 Worker Node에 문제가 발생하면 다른 Worker Node에서 Pod가 다시 생성될 수 있고 PodIP가 변경되기도 한다.
  • 동적으로 변하는 Pod에 가장 고정된 방법으로 접근하기 위해서 사용하는 것이 Service이다.
  • Service를 사용하면 Pod가 Cluster 내의 어디에 떠있는지 간에 고정된 주소를 이용해 접근할 수 있으며 Cluster 외부에서 Pod에 접근할 수 있다.
  • 하나의 서비스가 관리하는 Pod는 모두 동일한 구성을 갖는데 구성이 다른 Pod는 별도의 서비스로 관리해야 한다.
  • 여러 개의 워커 노드에 걸쳐 실행되더라도 동일한 구성의 Pod는 하나의 Service가 관리한다.
  • 서비스의 역할은 Load Balancer로 각 서비스는 자동적으로 고정된 IP(Cluster IP)를 설정해서 이 주소로 들어오는 통신을 처리하는 객체이다.

Docker: 컨테이너 단위로 애플리케이션을 실행

Kubernetes: Pod 단위로 컨테이너를 관리 (1개 이상의 컨테이너가 포함될 수 있음)

  • Pod들은 ReplicaSet을 통해 개수와 상태를 자동으로 관리
  • ReplicaSet은 다시 Deployment가 제어 (롤링 업데이트 등 지원)
  • 외부에서 Pod로 직접 접근 할 수 없다. (IP가 뭔지 모르니까) → Proxy 역할을 하는 누군가를 통해서 접근해야 한다. 이때 그 누군가가 Service
    • Service가 로드 밸런서 역할도 한다.
  • 내부적으로는 여러 개의 Pod가 있어도 밖에서는 하나의 IP 주소 (Cluster IP만 볼 수 있으며 이 주소로 접근하면 서비스가 통신을 적절히 분배해주는 구조이다.)
  • 서비스간 분배하는 통신은 한 Worker Node 안으로 국한되며 여러 Worker Node 간의 분배는 Load Balancer 또는 Ingress가 담당하는데 이들은 Master Node나 Worker Node가 아닌 별도의 노드에서 동작하거나 물리적 전용 하드웨어로 구현

종류

  • Cluster IP
    • 쿠버네티스 클러스터 내의 Pod들은 기본적으로 외부에서 접근할 수 있는 IP를 할당받지 않고 Cluster 내부에서 Pod들이 통신할 방법을 제공해 주어야 하는데 이 때 사용되는 것이 Cluster IP이다.
    • Cluster 내의 모든 Pod가 해당 Cluster IP 주소로 접근할 수 있다.

replica: 똑같은 걸 여러 개 만드는 것

web application2, 2, 2을 replica로 만들었어. (이때 web application2들은 ReplicaSet) 각각 cluster ip를 가지고 있고 외부 web application2랑 소통할 때 이 cluster ip를 사용한다.

  • Node Port
    • 서비스를 외부로 노출시킬 때 사용하는 것으로 노드 포트로 서비스를 노출하기 위해서 Worker Node의 IP와 포트를 이용하는데 Worker Node의 IP가 192.168.2.3(실제 IP)이고 30010이라는 NodePort를 사용한다면 외부에서 192.168.2.3:30010 이라는 주소로 접근이 가능하다.
  • Load Balancer
    • Public Cloud에 존재하는 Load Balancer에 연결하고자 할 때 사용하는 것으로 사용자는 Load Balancer의 외부 IP를 가지고 접근이 가능하다.
  • Ingress
    • URL, Hostname, Path 등과 같은 웹 개념을 이해하는 프로토콜로 인지형 설정 매커니즘을 이용해 HTTP(HTTPS) Network Service를 사용 가능하게 해주는 것으로 Kubernetes API를 통해 정해진 규칙에 기반해서 트래픽을 다른 백엔드에 매핑할 수 있게 해주는 매커니즘
  • External Name
    • 외부의 특정 FQDN(Fully Qualified Domain Name - 절대 도메인 네임, 도메인 네임 전체)에 대한 CNAME 매핑을 제공하는 것으로 Pod가 CNAME(별명)을 이용해 특정 FQDN가 통신하기 위한 개념
      • ex, www.naver.com(FQDN)을 자주 쓰니까 naver(CNAME)로 연결되도록 해버리기
    • Manifest
    apiVersion: v1
Kind: Service
spec:
      type: ClusterIp
      selector: ?

쿠버네티스 통신

  • 쿠버네티스에서 통신할 때 나타나는 특징
    • pod가 사용하는 Network와 Node가 사용하는 네트워크는 다르다.
    • 노드 내의 pod들은 가상의 Network를 사용하고 Node는 물리 Network를 사용한다.
    • 같은 pod 안에 있는 container 간의 통신
      • 기본적으로 같은 pod 내에 있는 container 간의 통신은 직접 통신(localhost)이 가능한데 하나의 pod에는 하나의 가상 network가 생성되고 그 pod 내에 존재하는 container 들은 가상 network를 모두 사용하기 때문이다.
      • 하나의 pod 내에 존재하는 Container들은 모두 동일한 IP를 사용한다.
      • 포트 번호를 이용해서 컨테이너를 구분한다.
    • 단일 Node 에서 pod 간 통신
      • 단일 노드에 떠 있는 pod들은 동일한 네트워크 대역을 사용하므로 docker0 이라는 브릿지를 이용해서 통신이 가능하다.
    • 여러 Node 에서 pod 간 통신
      • 게이트웨이 또는 라우터를 이용해서 통신한다.
      • 서로 다른 Worker Node에 존재하는 pod의 IP가 동일하게 할당되는 문제가 발생하는데 이 문제를 해결할 수 있는 것이 Overlay Network 이다.
        • 노드에서 사용하는 물리적인 Network 위에 가상의 Network를 구성하는 것
        • overlay network를 사용하면 kubernetes cluster로 묶인 모든 노드에 떠 있는 pod 간의 통신이 가능하다.
        • kubernetes는 overlay network를 구성하기 위해서 cluster로 묶을 때 CNI 규약을 따르는 plugin을 함께 설치하는 것을 강제한다.
        • kubernetes는 기본적으로 kubenet이라는 기본적이고 간단한 Network plugin을 제공하지만 다수의 노드에 떠있는 pod 간의 통신이나 network 정책 설정 같은 고급 기능은 제공하지 않기 때문에 CNI Spec을 준수하는 Network Plugin을 사용해야 한다.
  • 같은 Node에 떠 있는 pod 끼리는 통신할 수 있고 다른 Node에 떠 있는 pod 또는 외부와의 통신은 불가능하다.
  • 다른 노드의 pod와 통신하려면 CNI 플러그 인이 필요하다.
    • CNI(Container Network Interface)는 Conatiner간의 통신을 위한 네트워크 인터페이스이다.
    • Pod 간의 통신은 동일한 호스트(노드) 내에서만 가능하다.
    • 서로 다른 노드에 존재하는 pod끼리는 CNI Plugin을 이용해서 통신한다.
    • kubernetes에서 사용할 수 있는 CNI 플러그인
      • Flannel
      • Calico
      • Cilium
      • Multus

Pod와 Service 간 통신

  • Service의 특성
    • Service도 Pod와 같이 IP를 갖는다.
    • Pod와 Service에서 사용하는 IP 대역은 다르다. - Pod의 IP 대역은 10.244.1.x 이지만 Service 에서 사용하는 IP 대역은 10.101.x.x
    • Service에서 사용하는 가상 네트워크는 ifconfig나 Routing Table에서 확인할 수 없다.
  • Service IP와 관련된 정보를 Routing Table에서 확인할 수 없지만 외부에서 서비스 IP로 Service를 요청하면 Service IP는 특정 Pod에 요청을 전달한다.
  • Client Pod 에서 Service Name으로 http요청을 하면 Cluster DNS(Core DNS)는 Service Name에 해당하는 서비스 IP(10.5.1.10)을 Client Pod에게 전달하고 Service IP를 전달 받은 Client Pod는 해당 IP를 이용해서 http 요청을 하는데 이때 Worker Node 1이라는 호스트에서는 자신의 라우팅 테이블에 10.5.1.10이라는 IP가 있는지 검색하고 검색 결과 IP가 없으면 해당 요청을 라우터/게이트웨이로 전달하는데 다른 워커 노드에서도 10.5.1.10을 찾으려고 하는데 IP는 검색되지 않는다.
    • 10.5.1.10이라는 서비스 IP로 Web Server Pod(10.1.2.2)를 찾아갈 수 있도록 해주는 것이 리눅스 커널의 netfilter와 iptables
    • netfilter는 규칙 기반의 패킷 처리 엔진으로 서비스 IP를 특정 IP로 변경할 수 있는 규칙을 저장하고 변환하는 역할을 수행하는데 netfilter를 proxy라고도 한다.
    • netfilter에서는 서비스 IP를 만나면 실제 서버 IP로 변환하고 라우터/게이트웨이로 패킷을 전달하는데 동일한 작업이 여러 Worker Node에서 진행되고 이렇게 해서 서비스에 요청을 하면 실제 pod가 응답을 하는 것
    • —> 여기까지는 전부 클러스터 내부에서의 통신

클러스터 외부와 통신

  • Node Port
    • Node IP에 포트를 붙여서 외부에 노출시키는 것
    • Node의 IP가 192.168.10.2 라면 포트를 붙여서 192.168.10.2:30001 같은 형태를 만들어서 외부에 노출시킨다.
  • Load Balancer
    • Azure, AWS, GCP와 같은 Public Cloud에서 제공하는 Load Balancer와 Pod를 연결한 후 해당 Load Balancer IP를 이용해서 Cluster 외부에서 Pod에 접근할 수 있도록 해준다.
  • Ingress
    • Cluster 외부에서 내부로 접근하는 요청들을 어떻게 처리할지에 관한 규칙 모음으로 Ingress 자체는 Cluster 외부에서 URL로 접근할 수 있도록 Load Balancing, SSL 인증서 처리 등의 규칙을 정의한 것에 불과하며 실제로 동작시키는 것은 Ingress-Controller

Namespace

  • kubernetes에서는 Namespace라고 불리는 가상적인 kubernetes 클러스터 분리 기능이 존재하는데 완전한 분리 개념은 아니고 하나의 kubernetes 클러스터를 나누어 사용하기 위해서 사용한다.
  • 기본 설정에서는 4개의 네임 스페이스를 제공한다.
    • kube-system: kubernetes 클러스터 구성 요소와 애드온이 배포될 네임스페이스
    • kube-public: 모든 사용자가 사용할 수 있는 컨피그맵 등을 배치하는 네임스페이스
    • kube-node-lease: 노드 하드비트 정보가 저장된 네임스페이스
    • default: 기본 네임스페이스

kubectl

  • 쿠버네티스 명령을 전송하기 위한 CLI 도구
  • 인증 정보와 context(저장하는 것)
    • kubectl은 ./.kube/config에 kubeconfig에 쓰여있는 정보를 사용해서 접속한다.
    • clusters에 접속 대상 클러스터 정보, user에는 인증정보 등을 저장해 놓고 사용하는데 직접 편집하거나 kubectl 명령으로 설정을 변경해서 사용할 수 있다.
  • context를 전환
kubectl config use-context 컨텍스트이름
# 명령마다 명시
kubectl --context 컨텍스트이름 실제명령
728x90
반응형

'현대 오토에버 클라우드 스쿨' 카테고리의 다른 글

Kubernetes- Prune, 로그 확인  (3) 2025.07.01
Kubernetes- Pod  (2) 2025.06.30
Docker Swarm  (2) 2025.06.26
Docker Swarm  (1) 2025.06.25
Load Balancer  (0) 2025.06.25
'현대 오토에버 클라우드 스쿨' Related Articles more