한칸짜리책상서랍

리소스를 균등하게 사용하고 있는 3개의 Pod 를 가진 Node 가 있다. 각 Pod 가 Node 의 리소스를 균등하게 사용하고 있기 때문에 특정 Pod 에 추가 리소스를 할당 할 수 없는 상황에서 Pod1 이 추가 리소스를 필요로 하는 상황이 발생 했다. 그럼 Pod1 이 리소스 부족으로 에러가 발생하고 다운 되어야 할까? 아니면 다른 Pod2 나 Pod3 을 다운시키고 Pod1 에 추가 리소스를 할당 해야 할까? k8s 에는 Application 의 중요도에 따라 이런 상황을 핸들링 할 수 있도록 세 가지 단계로 Quality of Service 를 지원해주고 있다. 지금 상황에서는 BestEffort 가 부여 된 Pod 가 가장 먼저 다운이 되고 리소스가 반환 되고 Pod1 은 필요한 리소스를 제공..

Pod 를 만들면 그 안에 Container 가 생기고 Pod 와 Container 의 상태가 Running 이 되면서 그 안에 있는 Application 도 정상적으로 구동이 되고 있을 것이다. 그리고 Service 에 연결 되는데 이 Service 의 IP 가 외부에 노출되어 다수의 사용자에 의해 서비스가 이용 된다.현재 하나의 Service 에 두 개의 Pod 가 연결되어 있고 트래픽이 반으로 나뉜다고 하자. 이 때 Node2 서버가 문제가 생겨 다운이 된 경우 그 위의 Pod 도 Failed 가 되면서 사용자의 모든 트래픽이 Pod1 로 들어가게 된다.Pod1 이 트래픽을 견뎌준다면 서비스를 유지하는데 문제는 없다. 다운이 된 Pod2 는 Auto Healing 기능에 의해 다른 Node 에 생성..

Pod 에는 Lifecycle 이 존재하고 어떤 Pod 든 만들어지고 사라지는 과정을 거치게 된다. Lifecycle 은 각 단계 별로 하는 행동이 다르다는 특징을 갖는다. Pod 역시 단계별로 주요 행동들이 있고, 앞으로 알아 볼 ReadinessProbe, LivenessProbe, Qos, Policy 등 다양한 기능들이 Pod 의 특정 단계와 관련이 있기 때문에 Lifecycle 에 대해 잘 알아야 한다.Pod 를 생성하고 나면 아래와 같이 Status 에 대한 값을 확인할 수 있다.status: phase: Pending conditions: - type: Initialized status: 'True' lastProbeTime: null lastTransit..

DaemonSet, Job, CronJob Controller 가 무엇이고 언제 사용 하는지 정리 한다.DaemonSet각 Node 에 자원이 다르게 남아있는 상태에서 ReplicaSet 의 경우 Pod 를 Scheduler 에 의존해서 Node 에 배치할 때, 만약 Node1 에 자원이 많이 남아있는 경우 Pod 를 많이 배치할 것이다. 그리고 Node3 과 같이 자원이 별로 없으면 Pod 를 배치하지 않을 수도 있다.반면 DaemonSet 은 Node 의 자원 상태와 상관 없이 각 Node 에 Pod 가 하나씩 만들어진다는 특징이 있다. 만약 Node 가 10개면 각 노드에 하나씩 총 10개의 Pod 가 생긴다. 이렇게 각 Node 에 설치해서 사용해야 하는 서비스 들이 있다.각 Node 에 설치해서..

Deployment 는 하나의 운영 중인 서비스를 업데이트 하여 다시 배포해야 할 때 도움을 주는 Controller 이다.Deployment 에 대해 알아보기에 앞서 k8s 에서 사용하는 몇 가지 업그레이드 방법에 대해 알아 본다.업그레이드 방법에는 크게 ReCreate, Rolling Update, Bule/Green, Canary 등이 있다.ReCreateDeployment 를 만들면 v1 의 Pod 들이 만들어 진다. 그리고 각 Pod 마다 각자의 자원을 사용 한다고 할 때 ReCreate 방법으로 를 업그레이드를 하게 되면 Deployment 는 먼저 기존의 Pod 들을 삭제 한다. 그렇기 때문에 서비스에 대한 Downtime 이 발생 하고 자원도 사용하지 않게 된다. 그리고 나서 v2 의 Po..

k8s 의 Controller 는 서비스를 관리하고 운영하는데 큰 도움을 준다.Auto HealingNode 위에 Pod 가 있는데 이 Pod 가 갑자기 다운 되거나 이 Pod 가 Scheduling 되어 있는 Node 가 다운 될 경우 Controller 는 장애를 바로 인지하고 Pod 를 다른 Node 에 새로 만들어 준다.Software Update다수의 Pod 에 대한 버전을 upgrade 해야 할 경우 Controller 를 통해 한 번에 쉽게 할 수 있고, upgrade 도중에 문제가 생기면 rollback 할 수 있는 기능을 제공 한다.Auto ScalingPod 의 리소스가 최대치에 다다랐을 경우 Controller 는 이 상태를 파악하고 Pod 를 하나 더 만들어 줌으로 부하를 분산 시키..

본격적인 사용 방법을 알아보기에 앞서 Namespace, ResourceQuota, LimitRange 를 왜 사용해야 하는지 먼저 정리한다.k8s Cluster 라고 해서 전체 사용할 수 있는 자원이 있다. 일반적으로 Memory, CPU 가 있고 Cluster 안에는 다수의 Namespace 를 Namespace 안에는 다수의 Pod 를 만들 수 있다. 각 Pod 는 필요한 자원을 Cluster 자원을 공유하여 사용하는데, 만약 한 Namespace 안에 있는 Pod 가 Cluster 에 남은 자원을 모두 사용해버리면 다른 Pod 입장에서는 더 이상 사용할 수 있는 자원이 없어서 자원이 필요할 때 문제가 생기게 된다.이런 문제를 해결하기 위해 ResourceQuota 가 존재하는데 이것은 Namesp..

본격적인 사용 방법을 알아보기에 앞서 ConfigMap 과 Secret 이 언제 사용되는지 먼저 정리한다.개발 환경과 운영 환경이 있다. A Service 는 환경에 따라 SSH 설정 및 User 와 key 값을 설정해야 한다. 하지만 이 값은 Container 안에 있는 Service 에 들어있는 값이기 때문에 이 값을 바꾼다는 것은 환경에 따라 Container Image 를 따로 관리해야 한다는 것을 의미한다. 단순히 이 값을 관리하기 위해 용량이 큰 Image 를 별도로 관리하는 것은 부담되는 일이다.보통 환경에 따라 변하는 값들을 외부에서 결정할 수 있도록 한다. 이것을 도와주는 것이 ConfigMap 과 Secret 이라는 오브젝트 이다. 관리 해야 하는 일반적인 상수들을 모아 ConfigMa..

emptyDirContainer 간 데이터 공유를 위해 Volume 을 사용하는 것을 말한다. 최초 Volume 이 생성될 때는 항상 내용이 비어있기 때문에 emptyDir 이란 이름을 가지게 되었다.만약 Container 1 이 web 역할을 하는 서버이고 Container 2 는 백엔드를 처리해주는 서버라고 하자. 이 때 web 서버로부터 받은 파일을 mount 된 Volume 에 저장해두고 백엔드의 Container 역시 같은 Volume 을 mount 해두면 이 두 서버가 Volume 을 자신의 로컬에 있는 파일 처럼 사용할 수 있다. 즉 두 서버 간 파일 전송 없이 같은 파일을 사용할 수 있다.추가로 Volume 은 Pod 안에 생성되기 때문에 만약 Pod 에 문제가 발생하여 다시 생성 될 경우..

ClusterIPService 는 기본적으로 아래 그림과 같이 자신의 ClusterIp 를 가지고 있다.그리고 이 Service 를 Pod 에 연결시켜두면 Service 의 IP 를 통해 Pod 에 접근할 수 있게 된다.앞서 Pod 에도 동일하게 Cluster 내에서 접근할 수 있는 IP 가 존재함에도 불구하고 굳이 Service 를 붙여서 접근하는지 의문이 생긴다. 이렇게 하는 이유는 Pod 는 k8s 에서 다양한 이유로 언제든 다운될 수 있으며 언제든 다시 생성될 수 있는 오브젝트이기 때문이다. (다시 생성 될 경우 Pod 의 IP 는 매번 달라진다.)반면 Service 의 경우 사용자가 직접 명령을 하지 않는 한 스스로 삭제 되거나 다시 생성되지 않는다. 즉, 이 Service IP 를 사용하면 항..