오랜만에 `K8s` 공부를 다시 시작했다. 인프런의 일프로님의 강의를 보며 학습을 이어간다. 거두절미하고 `Pod`의 라이프사이클에 관해 정리한 내용을 포스팅하려 한다. Pod - LifeCycle`Pod`에는 라이프사이클이 존재하고 어떤 `Pod`든 생성되고 사라지기까지 일정한 단계를 거치게 된다. 그리고 `Pod` 라이프사이클의 특징은 각 단계에 따라 행해지는 행동이 다르기에 라이프사이클에 대해 잘 알아야 한다. `Pod` 라이프사이클 핵심 간단 정리PendingReadinessProbePolicyRunningLivenessProbeQosSucceededPolicyFailedUnknown 아래 사진은 `Pod`의 라이프사이클과 관련 요약이라고 생각하면 편할 것이다.  Pending -> Running..

Kubernetes  이번 포스팅에서는 컨트롤러에 대해 알아볼 것이다. `Kubernetes`의 컨트롤러는 여러 기능을 통해 서비스를 관리하고 운영하는데 큰 도움을 준다.  Auto Healing노드 위에 `Pod`가 있는데 해당 `Pod`가 갑자기 다운되던가 아니면 해당 `Pod`가 스케줄링 되어있는 노드가 다운되면해당 `Pod`에서 돌아가던 서비스에 장애가 온 것이다.이때, `Controller`는 이걸 즉각적으로 인지하고 `Pod`를 다른 노드에 새로 만들어준다.이걸 `Auto Healing` 기능이라고 한다. Auto Scaling`Pod`의 리소스가 리미트 상태가 됐을 때 `Controller`는 이 상태를 파악하고 `Pod`를 하나 더 만들어준다.즉, 부하가 분산되며 `Pod`가 죽지 않도록 ..

Kubernetes  이번 포스팅에서는 `Namespace`, `ResourceQuota`, `LimitRange`에 관해 알아보려 한다. 우선, 해당 오브젝트들을 왜 사용해야 되는지 먼저 알아보자.  `Kubernetes` 클러스터 안에는 사용할 수 있는 자원들이 존재한다. 일반적으로는 메모리나 CPU가 있을 것이다. 클러스터 안에는 여러 `Namespace`들이 존재하며 `Namespace` 안에는 여러 `Pod`가 생성이 가능하다. 각 `Pod`는 필요한 자원을 클러스터 자원을 공유해서 사용하는데,만약 한 `Namepsace` 안에 있는 `Pod`가 이 클러스터에 남은 자원을 모두 사용해 버리면 다른 `Pod` 입장에서는더 이상 쓸 자원이 없어서 자원이 필요할 때 문제가 발생한다. 이런 문제를 해결..

Kubernetes  이번 포스팅에서는 `ConfigMap`과 `Secret`에 관한 설명이다. 설명하기에 앞서 해당 오브젝트를 사용해야 하는 상황은 어떤 경우일까? 개발 환경과 상용 환경이 있다고 하자.또한, A라는 서비스가 있다고 가정하자. 이때, A 서비스에는 일반 접근과 보안 접근이 가능하다. A 서비스(개발 환경)SSH: FalseUser: DevKey: LS0tLs... 따라서, 개발 환경에서는 해당 보안 접근을 해제할 수 있는 옵션이 있다.(`SSH : False`)만약, 보안 접근을 한다면 접근 유저와 키를 세팅할 수도 있다.(`User: Dev`, `Key: LS0tLs`)  개발 환경에서는 위처럼 사용한다고 하고, 상용 환경에서 배포를 해야 한다면 해당 값은 변경되어야 할 것이다. A ..

Kubernetes  이번 포스팅에서는 `emptyDir`과 `hostPath` 그리고 `pvc`와 `pv`라고 하는퍼시스턴트 볼륨 클라임과 퍼시스턴트 볼륨에 관해 알아보도록 하자.   emptyDir 먼저 `emptyDir`은 컨테이너들끼리 데이터를 공유하기 위해 `Volume`을 사용하는 것이다.최초로 해당 `Volume` 이 생성될 때는 항상 해당 `Volume`안의 내용이 비어있기 때문에 `emptyDir`이라는 명칭이 붙어졌다. 만약, 컨테이너1이 웹 역할을 하는 서버이고 컨테이너2가 백엔드단을 처리해주는 서버라고 했을 때, 해당 웹서버로 받은 어떤 특정 파일을 마운트가 된 `Volume`에 저장을 해놓고,백엔드단의 컨테이너 역시 해당 볼륨을 마운트를 하면 이 두 서버가 해당 `Volume`을 ..

Kubernetes  Service  서비스는 기본적으로 자신의 `클러스터 IP`를 가지고 있다.그리고 이 서비스를 파드에 연결을 시켜 놓으면 서비스의 IP를 통해서 파드에 접근이 가능하다. 그런데, 전 포스팅에서 살펴본 것처럼 파드도 똑같이 클러스터 내에서 접근할 수 있는 IP가 있었다.  그렇다면 굳이 왜 서비스를 이용하는 것일까?  사용 이유 `Pod`라는 존재는 `Kubernetes`에서 시스템 장애건, 성능 장애건 언제든지 죽을 수가 있다.그리고 그때 다시 재생성 되도록 설계가 되어있는 오브젝트이다. 근데 이때, `Pod`는 재생성시 IP가 변경된다. 따라서, 이 파드의 IP는 신뢰성이 떨어진다.그러나, `Pod`와는 별개로 서비스는 사용자가 직접 지우지 않는 한 삭제되거나 재생성되지 않는다. ..