DevOps Story

시작하며... Kubernetes는 기본로 제공하는 Built-in Object(ex: Deployment, Service) 외에 따로 정의한 Custom Resource를 통해 클러스터의 기능을 확장시킬 수 있다. 예를 들어 Istio의 VirtualService나 DestinationRule, ArgoCD의 Project, Application 등을 예로 들 수 있다. 물론 Custom Resource만을 정의한다고 해서 새로운 기능을 추가할 수는 없으며, 'Custom Controller' 또는 'Operator'를 통해 built-in object와 custom resource에 대한 동작을 구현해야 한다. 참고로 k8s는 Custom Controller의 쉬운 구현을 위해 client-go 라이..

Kubernetes Components 아래 그림과 같이 Kubernetes에 존재하는 모든 Component 간 통신은 HTTPS를 기반으로 이루어지며, 모든 트래픽이 암호화되므로 데이터의 신뢰성과 보안을 보장할 수 있다. 일반적으로 K8s Component 사이에서 이루어지는 작업은 다음과 같이 요약할 수 있다. kube-apiserver -> etcd: kube-apiserver는 etcd에 접근할 수 있는 유일한 Component로, K8s 클러스터의 상태를 Key-Value 형식으로 etcd 저장소에 관리한다. kubelet -> kube-apiserver: Worker에 배치된 kubelet은 자신이 생성해야할 Pod 정보를 kube-apiserver로부터 가져온다. kube-apiserver..

Pod Pod은 Kubernetes에서 scheduling 가능한 최소한의 배포 단위로, Pod은 전체 생애에서 단 한번만 schedule된다. 다시 말해서 Node에 할당된 pod은 종료될 때까지, 해당 node에서만 존재할 수 있다는 이야기다. Pod 자체는 Self-heal이 불가능하므로 Fail 발생시 그대로 제거되며, 다른 UUID값을 갖는 Pod으로 대체된다. Pod Phase 'kubectl get pod -o yaml' 등의 명령어로 Pod의 디테일한 정보를 확인해보면, 사용자가 정의한 spec 외에 status 라는 필드가 존재한다. 그리고 이 필드에는 phase 항목이 존재하는데, 이는 Pod의 lifecycle이 현재 어느 단계에 있는지를 알려준다. 우선 Pod의 전체 Lifecycl..

이번엔 Calico를 구성하는 Component들에 대해 알아보자. 아래 그림은 Calico component와 관계를 설명하는 다이어그램이다. Felix Calico Datastore로부터 가져온 설정 정보에 맞게 Host의 인터페이스, 라우팅 테이블, iptables(kube-proxy 모드에 따라 IPVS가 될 수 있음)를 관리하여 패킷이 지정된 Pod에 정확히 전달될 수 있게 한다. 클러스터의 Network Policy를 위반한 패킷이 전송되지 않게 차단하는 ACL 기능도 제공한다. BIRD BGP Client 역할을 담당하는 Component다. Felix가 Route 정보를 Linux Kernel FIB(Forwarding Information Base)에 추가할 때, 이를 다른 Node에 공..

Namespace는 프로그래밍 언어 외에 다양한 컴퓨팅 분야에 널리 사용되는 개념이다. 하나의 namespace 안에서 이름과 개체(또는 자원)은 1:1로 매칭된다. 일반적인 정의는 다음과 같다. In computing, a namespace is a set of signs(names) that are used to identify and refer to objects of various kinds. A namespace ensures that all of a given set of objects have unique names so that they can be easily identified. - Wikipedia 예를 들어, C++, Java와 같은 프로그래밍 언어에서는 동일한 Namespace 안..

Container Runtime은 Pod 생성시, 다음과 같은 방법으로 CNI에게 Network 설정을 요청한다. CNI 플러그인이 지원해야하는 Operation CNI 플러그인은 실행가능한 파일로 구현하여, 각 Container Runtime Engine(Docker, rkt 등)에 의해 호출된다. 네트워크 인터페이스를 컨테이너의 Network Namespace에 추가하고, 호스트와 연결(veth pair)한다. 또한 IPAM 플러그인을 통해인터페이스에 IP를 할당하고, Routing Rule을 갱신할 수 있어야 한다. CNI Spec v0.4.0을 기준으로 다음과 같은 4개의 Operation을 지원해야 한다. ADD: 네트워크에 Container 추가 DEL: 네트워크에서 Container 제거 C..

시작하며... Kubernetes 클러스터를 직접 구축하는 경우, CNI 플러그인 설치를 요구받게 된다. 현재 시장에는 수십개 이상의 CNI 플러그인이 존재하며, 한번 설치하고나면 운영 중 다른 플러그인으로 교체는 결코 쉽지 않은 작업이 되므로 신중하게 선택해야 한다. 각 플러그인마다 수행방식이나 네트워크 모델이 제각각이며 장단점 또한 다르기 때문에 우리의 선택엔 확실한 근거와 기준이 필요하다. 이를 위해 Container와 Container, Container와 Host 사이에 어떻게 네트워크가 구성되는지 알아보도록 하자. 우선 Kubernetes의 Network Model은 아래와 같이 단순하지만 확고한 요구사항 3개를 명시해 놓았다. K8s Network Requirements Pod은 NAT을 사..

Scheduler는 K8s의 Control Plane Component 중 하나로, Pod을 어떤 Node에 생성할지 결정하는 역할을 맡고 있다. 기본적인 동작 원리는 다음과 같다. API Server는 Client(ex: Admin)로부터 Pod 생성을 요청받으면, 우선 이를 etcd에 저장한다. Scheduler는 API Server를 계속 확인하며 만약 새로운 Pod 또는 Node를 배정받지 못한(unscheduled) Pod이 있는 경우, 해당 Pod이 생성될 수 있는 최적의 Node를 찾아 API Server에 전달한다. 마지막으로, 선택된 Node에서 수행중인 kubelet은 API Server로부터 PodSpec을 전달받아 이를 생성한 뒤, Pod의 상태를 API Server에 보고하는 것으..