고정 헤더 영역
상세 컨텐츠
본문
시작하기에 앞서..
최근 어플리케이션의 규모가 방대해짐으로 인해서 IT 기업에선 MSA(Microservice Architecture)로의 전환에 집중하고 있다.
MSA의 가장 큰 특징은 모듈화, 독립성, 그리고 다양한 기술스택이다. 모듈화를 통해 각 기능을 독립적인 서비스로 분리하여 개발하고 운영할 수 있다. 또한, 독립적인 배포, 업데이트가 가능하기 때문에 한 서비스에 장애가 발생하더라도 전체 서비스에 영향을 주는 것을 방지할 수 있다. 마지막으로, MSA는 서비스별로 다양한 프레임워크를 사용할 수 있기 때문에 서비스 기능 최적화에 유리하다.
이러한 배경에서 소프트웨어공학 전공 수업에서 학습한 Docker, Kubernetes, Jenkins 등 클라우드 서비스와 관련된 기술들에 대해 정리하며 더 깊이 공부하기 위해 다시 Velog를 켜게 됐다.
Intro to Kubernetes
Kubernetes란?
Kubernetes의 사전적 정의는 'Container Orchestration Tool' 이다.
그렇다면, Container와 Orchestation은 대체 무슨 말일까?
Container란, 소프트웨어를 일관되고 독립적으로 실행할 수 있는 작은 단위로 패키징하는 기술 혹은 그 작은 단위를 지칭한다.
Container는 Pod에 담겨 배포 및 실행된다. 이때 Pod란 Kubernetes의 가장 작은 배포 단위이다. Pod 내의 컨테이너들은 자원을 공유하며, 같은 네트워크 네임스페이스를 사용한다. 이를 통해 서로 쉽게 통신하고 데이터를 공유할 수 있다. 하나의 Pod는 하나 혹은 여러 개의 Container를 담고 배포 및 실행한다. 하나의 Pod 내의 container들은 network namespace를 공유하며, localhost를 사용하여 상호 통신한다.
Orchestration이란, 여러 개의 컨테이너화된 애플리케이션을 관리하고 조율하는 과정을 말한다.
따라서, 정리하자면 Kubernetes는 분산 운영체제로서, 수많은 컨테이너들이 이질적인 배포 환경에서 실행될 수 있도록 돕는 도구이다.
Kubernetes 구조
Kubernetes(이하 K8s, 'ubernete'가 8글자라서 이렇게 줄여 말한다고 함)의 구조는 위의 그림과 같다.
K8 Cluster는 Master Node들과 Worker Node들의 집합으로 이루어져 있다.
또, Kubelets은 Worker Node에서 Master Node나 다른 Worker Node들과 대화하는데 사용된다.
Master Node
Master Node의 구성요소는 다음과 같다.
- API Server
- Scheduler
- Control Manager
- etcd
API Server는 K8 Operatoror API와 상호작용한다.
Scheduler는 Cluster 내에서 Pod들을 효율적으로 배치하고 관리한다.
Control Manager는 K8s Cluster의 상태를 관리하고 유지하며, 다음과 같은 역할을 한다.
- replication 관리 : replicaset, deployment 등의 복제본 관리
- service accounts 관리 : 서비스 계정과 액세스 토큰 관리
- namespace : namespace별 리소스 사용량을 모니터링하고 관리
마지막으로, etcd는 K8s Cluster의 상태 정보를 저장하고 관리하는 분산 키-값 저장소이다.
Worker Node
Worker Node의 구성요소는 다음과 같다.
- Kubelet
- Pod
- Kube-proxy
Kubelet은 Pod 안의 Container들을 실행한다.
Pod는 K8s의 최소 제어 단위로, 다음과 같은 특징들을 가진다.
- 각 Pod에는 Internal IP Address가 부여된다.
- 이때 부여되는 주소는 Ephemeral IP Address(임시 IP 주소)이다.
- Pod 내부의 Container들은 network namespace를 공유한다.
Kube-proxy는 Service의 DNS 이름을 통해 Pod로의 연결을 관리하여 인터넷 사용자가 Pod에 접근할 수 있게 한다.
Kubernetes 주요 개념
Service
Service란 각 Microservice들을 식별하고 연결하기 위한 리소스로, 다음의 기능을 제공한다.
- Load Balaning : 클라이언트의 요청을 적절한 Pod로 분산
- Naming : Microservice를 고유한 이름과 IP 주소(= namespace)로 추상화하여, 다른 Microservice에서 참조할 수 있게 함.
++ Service와 Pod가 계속 헷갈려서..
- Pod는 Kubernetes 클러스터 내부에서만 접근 가능한 IP 주소를 가진다.
- Service는 클러스터 내부 또는 외부에서 접근 가능한 IP 주소와 포트를 가진다.
- Service는 Pod에 대한 네트워크 추상화 계층을 제공한다.
Namespace
Namespace는 Microservice의 고유한 이름으로, Microservice 간 격리와 접근 제어를 실현하며, 다음의 기능을 제공한다.
- K8s에서 리소스를 논리적으로 분리
- 각 Microservice는 자신만의 Namespace를 가지며, 이를 통해 리소스 및 접근 권한을 독립적으로 관리함
- Microservice 간 상호 작용을 제어. (다른 Namespace의 리소스에 대한 접근을 제한)
Ingress
Ingress는 다수의 Microservice를 단일 API 엔드포인트로 통합하는 역할을 하며, 다음의 기능을 제공한다.
- K8s에서 외부 트래픽을 Microservice로 라우팅
- 다수의 Microservice를 단일 API 엔드포인트로 결합
- URL 기반 라우팅, SSL/TLS 종료, 부하 분산 등의 기능을 제공
Implementing Kubernetes
Kubeadm
Kubeadm란?
K8s Cluster를 빌드하고 유지하는 툴
Kubeadm 명령어
- $ Kubeadm init : Control Plane을 초기화하는 명령
- $ Kubeadm join : Worker Node를 초기화하고 Cluster에 가입시키는 명령
- $ Kubeadm token : Control Plane과 Worker Node들 사이의 인증을 하는 명령
- $ Kubeadm reset : Kubeadm init과 Kubeadm join을 초기화하는 명령
cf. kubectl : K8s의 공식적인 클라이언트. K8s API와 상호작용하기 위한 CLI 툴.
Yaml 파일
Yaml 파일이란?
K8s의 Component들(Service, Deploy, Pod 등)의 형상(Configuration)을 기재한 선언문.
Yaml 파일의 내용은 다음의 세 가지 항목으로 구분할 수 있다.
- metadata : k8s에 의해 자동 생성, 지속적으로 update됨
- spec : K8s의 self-healing 기능을 위한 desired state를 정의
- status : 실시간 status data를 포함. ectd에 저장
Kubernetes Service Network
외부 트래픽을 K8s Cluster에 연결하는 3가지 Service
1. Ingress
- ClusterIP service를 통해서는 cluster 내부에서만 pod 접근 가능 (internal service)
- Ingress는 Cluster 외부의 클라이언트가 Cluster 내부의 서비스에 접근할 수 있도록 HTTP 및 HTTPS 트래픽을 라우팅함.
또한, 도메인 기반 라우팅, SSL/TLS 종료 등의 기능을 제공함
2. NodePort
- NodePort Service는 static port 번호를 cluster에게 지정하여 외부에서 접근하도록 함.
- NodePort Service는 ClusterIP Service를 자동으로 생성하여 사용. (즉, ClusterIP Service를 외부 접근이 가능하도록 확장한 것)
3. LoadBalancer
- LoadBalancer Service는 nodePort Service를 확장한 것으로서, Cloud provider가 제공하는 NLB 사용.
- LoadBalancer Service가 자동으로 NodePort와 ClusterIP Service들을 생성. (즉, 내부 port번호를 제공하지 않도록 NodePort Service를 확장한 것)
지금까지 살펴본 내용을 바탕으로, 아래 그림을 보면 3가지 Service들을 직관적으로 비교할 수 있다.
Kubernetes Service Network
- service 네트워크는 실제 네트워크 device에 연결된 physical 또는 virtual 네트워크가 아니지만, 네트워크 전체의 IP table에 routing rule을 반영하여 실질적으로 네트워킹 기능을 함.
- Service IP(cluster IP)-to-Pod IP mapping 을 위해 control plane의 API server는 service, pod가
새로이 생기거나 제거되면 모든 노드의 kube-proxy에게 해당 Service IP(cluster IP)-to-Pod IP
mapping을 반영하도록 명령 - Kube-proxy는 kernel 모듈인 iptables를 사용하여 해당 IP address mapping을 routing table에
반영하여 netfilter가 ip routing table을 참조하여 목적지 ip 주소를 translate하여 (즉, ip routing
table에 있는 대로 목적지 서비스의 주소를 해당 pod의 pod ip 주소로 변경하여) routing이
되도록 함 - Kube-Proxy는 k8s의 모든 worker 노드에 하나씩 장착됨
마무리하며..
개발팀(Dev Team)이 프론트엔드, 백엔드, DB를 개발하고, 클라이언트가 해당 서비스에 접근을 요청할 때, 운영팀(Ops Team)은 Client가 서비스에 적절한 방법으로 접근할 수 있게 해야 한다. 이때 DevOps는 K8s Yaml 파일을 통해 Deploy, Scaling, Networking, Monitoring 등의 일련의 과정을 자동화할 수 있다.
서두에 말했다시피, 요즘 웹/앱 어플리케이션이 점차 MSA로의 전환을 이루고 있기 때문에 서비스 구조와 접근 과정은 점점 복잡해질 것이고, 이에 따라 DevOps의 역할은 점점 더 중요해질거라고 생각한다.
