2023-11-09-TIL

2023-11-09-TIL

Today I Learned

Today I Studied

Kubernetes Namespace

쿠버네티스의 네임스페이스는 논리적으로 분리함으로써 완전히 격리 시키기 위한 고유 주소이다. 리눅스 시스템에서 사용하는 네임스페이스와 같은 의미로 이해해도 될 것 같다.

공식 문서를 읽고 나니 이 이해는 조금 고쳐야 한다. 쿠버네티스 네임스페이스는 하나의 클러스터 안에서 리소스 묶음을 나누는 장치이고, 핵심은 이름의 범위(scope)다. 리소스 이름은 네임스페이스 안에서만 유일하면 되고, 네임스페이스는 중첩할 수 없으며, 리소스 하나는 한 네임스페이스에만 속한다. 리소스 쿼터로 팀별 사용량을 나누는 단위로도 쓰인다. 반면 파드 사이의 네트워크까지 자동으로 막아 주지는 않으므로, 완전한 격리가 필요하면 NetworkPolicy나 RBAC 같은 장치를 함께 써야 한다.

리눅스 네임스페이스는 이름만 같고 층위가 다르다. 프로세스가 보는 PID, 네트워크, 마운트 등을 커널 수준에서 분리하는 기능이고, cgroups와 함께 컨테이너를 만드는 재료다. 링크 중 faun.pub 글이 이 관계를 다룬다. 문서는 사용자가 적은 클러스터라면 네임스페이스를 따로 고민할 필요가 없고, 같은 소프트웨어의 버전 차이처럼 조금 다른 리소스를 나누는 데는 네임스페이스 대신 레이블을 쓰라고 권한다.

• https://kubernetes.io/docs/tasks/administer-cluster/namespaces/
• https://www.vmware.com/topics/glossary/content/kubernetes-namespace.html
• https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
• https://artist-developer.tistory.com/33
• https://www.linkedin.com/pulse/understanding-linux-namespace-types-luis-soares-m-sc-
• https://faun.pub/kubernetes-story-linux-namespaces-and-cgroups-what-are-containers-made-from-d544ac9bd622

---

Kubernetes Label, Annotation

둘 다 오브젝트에 붙이는 키-값 메타데이터지만 용도가 다르다.

• 레이블: 오브젝트를 식별하고 묶는 속성이다. 셀렉터로 레이블을 조건 삼아 오브젝트를 고른다. Service가 트래픽을 보낼 파드를 고르거나 Deployment가 관리할 파드를 고르는 것이 모두 레이블 셀렉터다. app=web 같은 등호 기반 조건과 env in (prod, staging) 같은 집합 기반 조건이 있다.
• 어노테이션: 식별에 쓰지 않는 임의의 메타데이터다. 빌드 정보, 담당자 연락처, 도구가 읽는 설정 값처럼 셀렉터로 고를 일은 없지만 오브젝트에 붙여 두고 싶은 정보를 넣는다.

네임스페이스와 레이블 중 무엇으로 나눌지 묻는 Stack Overflow 질문도 같은 기준으로 답할 수 있다. 접근 권한과 쿼터를 나눠야 하면 네임스페이스, 같은 공간 안에서 골라내기만 하면 되면 레이블이다.

• https://medium.com/dzerolabs/just-in-time-kubernetes-namespaces-labels-annotations-and-basic-application-deployment-f62568a9eaaf
• https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
• https://stackoverflow.com/questions/47441565/label-selector-vs-namespaces
• https://theithollow.com/2019/01/31/kubernetes-services-and-labels/
• https://medium.com/avmconsulting-blog/node-labels-and-selectors-in-kubernetes-76fbd8a8940c
• https://blog.kubecost.com/blog/kubernetes-labels/
• https://www.youtube.com/watch?v=zsovXtOFhDE
• https://anggeum.tistory.com/entry/Kubernetes-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EB%A0%88%EC%9D%B4%EB%B8%94-%EC%96%B4%EB%85%B8%ED%85%8C%EC%9D%B4%EC%85%98-Label-Annotation-Deep-Dive

---

Kubernetes Pod

공식 문서는 파드를 쿠버네티스에서 만들고 관리할 수 있는 가장 작은 배포 단위로 정의한다. 파드는 컨테이너 하나 이상의 묶음이고, 묶인 컨테이너는 저장소와 네트워크를 공유한다. 같은 파드의 컨테이너끼리는 localhost로 통신할 수 있다. 보통은 컨테이너 하나짜리 파드를 쓰고, 로그 수집기 같은 보조 컨테이너(사이드카)가 필요할 때 여럿을 묶는다.

문서는 파드를 직접 만들 일은 거의 없다고 강조한다. 파드는 비교적 일시적이고 버려지는 존재로 설계되어, 노드가 죽으면 그 위의 파드도 사라진다. 그래서 Deployment나 Job 같은 워크로드 리소스가 원하는 개수의 파드를 유지하도록 맡긴다.

• https://akasai.space/kubernetes/about_pod/
• https://www.redhat.com/ko/topics/containers/what-is-kubernetes-pod
• https://kubernetes.io/ko/docs/concepts/workloads/pods/
• https://seongjin.me/kubernetes-pods/

---

Kubernetes Probe

스프링 부트에서 probe를 위한 health check api는 직접 작성하지 않아도 액츄에이터 설정만으로 연동 가능하다. 스프링 부트 2.3 이상의 버전에서만 가능한 것 같다.

쿠버네티스 문서는 프로브를 세 가지로 나눈다.

• Liveness probe: 컨테이너를 재시작할지 판단한다. 프로세스는 살아 있지만 교착 상태에 빠져 진행하지 못하는 경우를 잡는다.
• Readiness probe: 트래픽을 받을 준비가 됐는지 판단한다. 실패하면 재시작하지 않고 Service의 트래픽 대상에서만 뺀다.
• Startup probe: 시작이 끝났는지 판단한다. 성공하기 전까지는 다른 두 프로브를 실행하지 않아서, 기동이 느린 애플리케이션이 liveness 실패로 재시작되는 일을 막는다.

Spring 블로그에 따르면 이 기능은 Spring Boot 2.3에 들어왔다. 애플리케이션 상태를 LivenessState와 ReadinessState로 표현하고, Actuator가 이를 /actuator/health/liveness와 /actuator/health/readiness로 노출한다. 이 HTTP 프로브는 쿠버네티스에서 실행될 때만 자동으로 설정되고, 로컬에서 확인하려면 management.health.probes.enabled=true를 켜면 된다. 그래서 2.3 이상이라는 짐작이 맞다.

• https://medium.com/finda-tech/kubernetes-pod%EC%9D%98-%EC%A7%84%EB%8B%A8%EC%9D%84-%EB%8B%B4%EB%8B%B9%ED%95%98%EB%8A%94-%EC%84%9C%EB%B9%84%EC%8A%A4-probe-7872cec9e568
• https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot
• https://www.baeldung.com/spring-liveness-readiness-probes