Kubernetes(쿠버네티스)의 정의
쿠버네티스는 컨테이너화 된 응용 프로그램의 배포(deployment), 확장(scaling) 및 관리(management)를 자동화하는 오픈 소스 시스템입니다.
kubernetes Cluster
쿠버네티스는 기능에 따라 Master와 Worker Node로 나눌 수 있고 이들의 집합을 Cluster라고 한다.
Node : 하나 이상의 Container를 지원하는 IT Resouce의 logical한 모음, 작업이 돌아가는 Infra System의 단위로서 pod가 올라가게 된다.
pod : Container가 동작되는 기본자원 → 기본 단위
Master
kubernetes는 Container를 관리, 확장, 연결해주는 소프트웨어이다. 그러면 이러한 작업을 수행하는 무언가가 필요로 하게 되는데 그것이 Master이다. 즉 Master는 종합관리를 해주는 소프트웨어이다. Master는 컨테이너들을 Worker Node에 적절하게 분배해주는 역할 등을 수행한다.
이제 Master의 구성 요소에 대해서 살펴보자
API Server : 모든 명령이 통하고, 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. API Server는 요청을 받아 처리하고 etcd에 기록하는 역할을 수행한다. RESTful API 형태이다.
Scheduler : 요청된 Container화 된 Workload를 어느 Node에 배치를 시킬지 결정해준다. kubelet과 정보교류를 통해 각 Node의 상황을 보고 결정한다.
Controller Manager : 다양한 Controller(복제, 배포, 상태, …)를 관리하고 API Server와 통신하여 작업을 수행한다.
etcd : cluster 내부의 설정 및 상태 정보를 저장하는 분산형 Database로 key-value 형태를 가진다. → 가볍고 빠르다.
Worker Node
Pod : 컨테이너가 동작되는 기본자원
kubelet : Master의 API Server와 통신하여 Pod를 생성하고 상태를 관리한다. API Server로 부터 확인한 Node의 상태(요구)를 실현하기 위해 동작한다.
kube-proxy : 클러스터의 각 노드에서 구동되는 쿠버네티스 네트워크 프록시이다. Node내의 특정 Container와 접촉(통신)을 하고자 할 때 proxy를 통해 IP 주소등을 확인해 접속할 수 있게 지원한다.
container engine : Node내의 가상화의 기반으로 여러 엔진이 있다.
kubernetes의 기본적인 Networking과 Service
Private IP와 Public IP
Public IP 주소 : unique해야 된다. 외부와 통신을 해야되기 때문에
Private IP 주소 : 중복이 가능하지만 외부와의 통신에서는 사용할 수 없다.
외부에서 k8s에 접근을 하고 싶다면 접근을 하려는 노드(pod)에 외부 접속 주소(public IP address)가 필요하다.
또한 k8s 내부의 pod, service들은 내부적인 private ip address가 필요하다. (내부적인 통신을 위한 IP 주소가 필요)
Container Network 기초 : Network Namespace
인프라 전체는 기본이 되는 Network Namespace인 Root network namespace
각 pod별로는 독립된 Network Namespace를 가진다. → Isolation을 지니게 되고 Network가 따로 존재하는 것처럼 보이게 해준다.
이렇게 나눠진 network들은 같은 subnet 영역에 있게되고 서로간의 통신은 bridge와 switch로 연결해서 통신한다.
결론적으로 설명하면 Network Namesapce는 Pod 각각을 Isolation 시키기 위해서 사용한다.
k8s Network Basic
k8s의 네트워킹은 아래의 규칙들을 따른다. 그 전에 모든 Container들은 Pod로 존재하고 Pod에 주소가 부여된다는 점을 알고 해당 규칙들을 알아보자
- All Containers can communicate with all other containers without NAT → 모든 Container는 서로 간의 통신을 할 때 NAT를 쓰지 않는다.
- All nodes can communicate with all containers (and vice-versa) without NAT → 다른 Node에 있는 Container도 같은 주소 체계를 가지고 이런 특징으로 NAT 없이 통신을 한다. → Cluster 내부의 basic한 networking은 모든 요소들이 동일한 Network에 있는 것처럼 보이게 한다.
- The IP that a container sees itself as is the same IP that others see it as → 컨테이너가 자신을 보는 IP는 다른 사람이 보는 IP와 동일하다.
- IP range from which to assign service cluster IPs. → 내부의 구성요소들에게 주소를 부여하는 주소풀에 맞춰서 부여한다.
Kubernetes Network 기초
Kubernetes의 IP 주소는 cluster를 꾸밀 때 설정한 IP 주소 범위안에서 자동으로 붙는데 Pod별로 IP 주소가 할당되고, Service별로 IP 주소가 할당된다. 또한 그림을 잘 살펴보면 kubernetes의 network는 flat한 network임을 알 수 있다.
노드의 IP 주소는 외부와 통신을 해야하는 경우 Public IP 주소가 할당이 된다. 그 외의 나머지 Service IP, Pod IP는 Private한 주소를 가지고 클러스터 내부의 통신에 사용이 된다.
Kubernetes에서 Service란?
Pod 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법.
→ Pod들을 logical하게 묶어놓은 set이고, 해당 set을 어떻게 access할지의 policy를 정의한다.
즉 우리가 Pod를 클러스터 내부, 외부에서 접근하게 만들고 싶을 때 사용하는 Object이다.
LabelSelector에 의해 선택된 Label 값을 가지는 pod들이 Service로 묶인다. → 해당 Service는 Service만의 주소를 사용한다.
Service의 종류에는 크게 2가지가 있다.
ClusterIP: Cluster 내부에서 접근이 가능하게 하는 Private IP 주소를 제공하는 Service
→ port에 들어가는 정보 : port(Service의 port), targetPort(pod의 port)
NodePort: Cluster 외부에서 접근이 가능하게 하는 Public IP 주소를 제공하는 Service → 외부에서 IP주소와 NodePort 번호를 알면 외부에서 접근이 가능해진다.
→ port에 들어가는 정보 : port(Service의 port), targetPort(pod의 port), nodePort(외부에서 접근하려고 할 때 사용하는 port)
이러한 서비스를 사용하는 이유는 Pod는 문제가 생기면 사라질 수 있어서 Pod의 IP 주소는 유한하지 않을 수 있다. → Pod의 IP 주소를 다시 알아내는 과정이 필요하게 된다. 하지만 해당 Pod를 Service로 묶으면 Service의 IP 주소로 접근을 할 수 있게 된다. → Service의 IP 주소는 변할 가능성이 거의 없다.
그러면 Pod가 여러개인 Service에서 Mapping은 어떻게 할까? → Load balancer가 존재하여 어떤 Pod로 보낼지 결정해준다.
