Cloud_TIL

Kubernetes가 지원하는 AutoScaling 방식은 HPA (Horizontal Pod AutoSacler) VPA (Vertical Pod AutoScaler) CA (Cluster AutoScaler) 가 있다. HPA (Horizontal Pod AutoSacler) HPA는 Replicas 수에 따라 Pod가 운영중이고 트래픽이 많아져 그 Pod의 리소스를 전부 사용한 경우에, Controller와 연결된 HPA가 Pod의 리소스를 미리 감지하고 있다가 위험한 상황이 오면, Controller의 Replicas 수를 자동으로 늘려주는 작동 방식이다. 이에 따라 Pod의 수가 늘어나게 되는데 이것이 Scale Out이며, 리소스 상황에 여유가 생기면 다시 Replicas 수를 줄여 Pod를 ..

이번에는 두 가지 부분에서 Kubernetes의 Ingress가 어떻게 사용되는지 확인해보려 한다. Service LoadBalancing Canary Update Service LoadBalancing 하나의 사이트를 운영중일 때 각 기능별로 Pod를 나누게 된다면 한 쪽의 기능에 문제가 생겼을 때 다른 기능에는 영향이 끼치지 않는다는 점이 Pod관리의 장점일 것이다. 각 기능은 다시 도메인에 /path를 붙여줌으로써 사용자가 각 서비스에 접근할 수 있도록 해주어야 하는데, Kubernetes에서는 이러한 도메인 구분을 Ingress를 통해 나눌 수 있다. Ingress를 사용하기 위해서는 Ingress Controller가 필요한데 Nginx, Kong 등을 통해서 환경을 실행해줄 수 있겠다. Can..

이번에는 Kubernetes의 StatefulSet에 대해 알아보려한다. Stateless Application stateless Application은 주로 애플리케이션이 여러 개 배포되더라도 다 같은 서비스로 유지된다. 주로 Web Server (Apache, Nginx, IIS) 와 같은 애플리케이션에 유용하다. 만일 하나의 애플리케이션이 죽을 경우, Stateless는 단순히 같은 서비스의 역할을 하는 앱을 복제하는 것으로 재생성 할 수 있다. stateless Application은 대체로 사용자들이 네트워크에 접속하고, 트래픽은 한 애플리케이션에만 집중되면 서버에 문제가 생기기 때문에 여러 애플리케이션에 분산시키는 형태로 흘러간다. 이러한 Stateless Application은 앞서 포스팅했..

이번에는 Kubernetes에서 지원하는 API 접근제어 정책으로 Authentication, Authorization에 대해 알아보도록 하겠다. Authentication 사용자가 Kubernetes Cluster로 Https 접근을 하기 위해서는 쿠버네티스 설치시에 클러스터로 접근할 수 있는 정보가 담긴 파일을 Kubeconfig에 담아두어야 한다. 즉, 클라이언트 인증서가 kubeconfig에 저장되어 있으면 된다. kubeconfig에는 CA crt, Client crt, Client key가 포함되어있다. 기본적으로 저장되는 장소는 /etc/kubernetes/admin.conf인데 내부를 확인해보면 각각의 인증서가 base64로 인코딩된 상태로 저장되어 있다. 각각의 인증서 내용을 확인해보기 ..

Kubernetes의 Volume을 사용하는 구조에서 앞서 PVC / PV를 이용하는 방식을 알아볼 수 있었다. 이번에는 PVC / PV 개념에서 한층 더 나아가 사용자가 PVC를 만들면 알아서 PV를 만들고 실제 Volume과 연결해주는 기능인 Dynamic Provisiong에 대해 알아보려 한다. Dynamic Provisioning Dynamic Provisiong을 사용하기 위해 Kubernetes에서는 StorageClass 오브젝트를 사용할 수 있다. PVC를 만들 때 StorageClassName 부분에 StorageClass의 이름을 넣어주게 되면, 자동으로 StorageVolume을 가진 PV를 생성할 수 있다. 또한 Volume의 status Lifecycle에 대해 알아보자면, 최초..

이번에는 Kubernetes의 Service를 조금 더 깊게 파고자 한다. 1. Headless Headless 서비스는 한 Pod가 Service를 거치지 않고 Service 내부에 있는 Pod에 직접 접근하고 싶을 때 사용할 수 있다. 서비스는 Headless를 이용하여 Cluster IP를 설정하지 않고 (None) Pod에 hostname과 subdomin을 부여함으로써 Pod의 DNS를 통해 직접 접근할 수 있다. 2. Endpoint 기존에 서비스 - Pod간 연결은 Selector를 통해 할당이 되는데, Endpoint를 통해 서비스의 이름과 IP 정보를 넣게되면 selector 없이도 연결이 가능하다. 3. ExternalName 외부의 특정 사이트에서 데이터를 가져오는 상황에서 접근 주소..

이번에는 Kubernetes Pod가 노드에 할당되기 위한 Scheduling에 대해 알아보려한다. 1. QoS QoS는 노드에 균등하게 자원을 배분한 Pod가 사용되고 있을 때, 만약 Pod에 추가적인 자원이 필요할 때 더 이상 노드에 여유 자원이 없는 경우를 대비해 설정할 수 있는 제약 조건이다. Pod를 생성할 떄 Pod는 다음 QoS 클래스 중 하나를 선택할 수 있다. Guaranteed Burstable BestEffort 1. Guranteed Guaranteed는 모든 Container에 Request와 Limit가 설정되어 있으며, Request와 Limit에는 memory, cpu상한과 요청량이모두 설정되어 있고, 각 컨테이너에 할당된 memory와 cpu의 Request와 limit 값..

이번엔 Kubernetes Pod의 생명주기(Lifecycle)를 알아보도록 한다. 기본적으로 Pod의 Lifecycle phase는 Pending, Running, Succeeded, Failed 그리고 Unknown의 단계로 나뉜다. 1. Lifecycle Phase Pod가 처음 만들어지기 시작하는 시점이다. Pending 상태일 때 Pod 안에서는 initContainer를 통해, 본 컨테이너가 기동되기 전에 초기화 스크립트를 작성하면 Pod를 initalize하는 동안 설정이 적용된다. Pod가 Pending되는 동안 Container는 Creating중 이기 때문에 Waiting 상태가 된다. 정상적으로 Container가 기동되게되면 Pod와 Container의 상태는 모두 Running이 ..

Controller의 마지막으로 DaemonSet과 Job, CronJob에 대해 알아보려한다. DaemonSet 통상 ReplicaSet을 사용할 경우 각 노드에 자원이 다르게 남아있는 상태에서 Pod를 배치할 때 자원이 많이 남아있는 노드부터 Pod를 배치하게 된다. 반면 DaemonSet은 자원상테에 상관없이 모든 노드에 Pod를 하나씩 생성하는 특징이 있다. 각 노드들의 성능 상태를 감시하기 위한 성능 수집 (ex. Prometheus) 특정 노드에 장애가 발생했을 경우 로그를 수집하기 위한 용도 (ex. fluentd) 네트워킹 관리를 하기 위해 각 노드에 DaemonSet으로 프록시 역할을 하며 네트워크를 관리하기 위한 스토리지 활용 용도 (ex. GlusterFS) 등에 대표적으로 사용하곤 ..

이번에는 kubernetes에서 운영중인 서비스를 업데이트하여 재배포 할 시 사용되는 기능들에 대해 알아보겠다. Deployment Controller는 크게 4가지로 구성할 수 있다. ReCreate Rolling Update Blue / Green Canary ReCreate ReCreate는 일시적인 서비스 정지가 가능한 곳에서 사용된다. ReCreate로 업데이트를 수행할 경우 기존 사용되던 Pod를 삭제하고 새로운 Pod를 만들어 Service에 연결하게 되는데, 이 때 기존의 Pod를 삭제하면서 잠깐의 Downtime이 발생하게 된다. 따라서 이러한 서비스 중단을 감안할 수 있는 곳에서 쓰일 수 있다. 참고로 revisionHistoryLimit를 이용하여 limit 수 만큼의 업데이트 이전 ..