37 posts tagged with "kubernetes"

Kubernetes에서 파드의 Readiness 및 프로브는 파드의 상태를 모니터링하고 트래픽을 효율적으로 관리하기 위한 중요한 메커니즘이다. 프로브는 파드가 요청을 처리할 준비가 되었는지를 판단하는 데 사용되며, Kubernetes가 파드를 관리하고 업데이트하는 데 중요한 역할을 한다.

파드 Readiness 및 프로브​

파드 Readiness는 따라 파드가 트래픽을 처리할 준비가 되었는지를 나타내는 추가적인 지표이다. 파드 Readiness는 외부 소스에서 파드 주소가 Endpoints 객체에 표시되는지를 결정한다. Kubernetes에서 파드를 관리하는 다른 리소스들, 예를 들어 Deployment 같은 것들은 파드 Readiness를 고려하여 롤링 업데이트 시 의사 결정을 한다. 롤링 배포 중에 새 파드가 준비되었지만 서비스, 네트워크 정책 또는 로드 밸런서가 어떤 이유로 인해 아직 새 파드에 대해 준비되지 않은 경우가 있을 수 있다. 만약 파드의 Readiness 프로브가 실패하면, 해당 파드의 IP 주소는 Endpoints 객체에서 제거되어 서비스가 그 파드로 트래픽을 라우팅하지 않는다. 이는 서비스 중단을 방지하기 위한 메커니즘이다. Readiness 프로브는 파드 .Status.Phase 에 영향을 줄 수 있으며, Kubelet이 이를 실행하여 성공 또는 실패에 따라 파드 상태를 업데이트한다.

파드에 프로브가 명시되어 있지 않으면 Kubernetes가 기본적으로 해당 프로브의 상태를 성공으로 간주한다. 이런 경우 Kubernetes가 컨테이너를 Ready 상태로 간주하여 서비스의 Endpoints에 포함시키고 트래픽을 받을 수 있도록 한다. 그러나 이는 실제로 컨테이너가 준비되지 않았을 때도 트래픽을 받을 수 있어 사용자 경험에 부정적인 영향을 미칠 수 있다. 따라서, 애플리케이션의 상태를 정확히 반영하기 위해 적절한 프로브를 설정하는 것이 중요하다.

컨테이너 내부에서 실행 중인 애플리케이션이나 프로세스는 시스템 호출(system call)을 수행할 수 있다. 대표적인 예로 HTTP 요청을 수행하는 curl 명령을 들 수 있다. 시스템 호출은 커널에 서비스를 요청하기 위해 사용자 공간에서 실행되는 추상화된 프로그래밍인데, 커널 강화 도구를 사용하여 허용되는 시스템 호출을 제한할 수 있으며, CKS 시험에서는 AppArmor와 seccomp라는 두 가지 도구를 명시적으로 언급하고 있다. 이 두 도구는 컨테이너화된 환경에서 보안을 강화하는 데 중요한 역할을 하며, Kubernetes와의 통합을 통해 보다 안전한 클러스터 운영을 지원한다. 이 두 도구와 쿠버네티스와 통합하는 메커니즘에 대해 설명한다.

AppArmor​

AppArmor는 Linux 시스템에서 실행되는 프로그램에 대한 액세스 제어 기능을 제공한다. AppArmor는 경로 기반으로 작동하며, 프로필을 통해 특정 프로그램이나 컨테이너가 필요한 접근만 허용하도록 설정할 수 있다. Kubernetes에서는 AppArmor 프로필을 Pod 또는 컨테이너 수준에서 지정할 수 있으며, securityContext를 통해 적용한다. 이 도구는 user space에서 호출되는 애플리케이션과 기본 시스템 기능 사이에 추가적인 보안 계층을 구현한다. 네트워크 호출 또는 파일 시스템 상호 작용을 제한할 수 있다. 많은 Linux 배포판(예: Debian, Ubuntu, openSUSE)이 AppArmor를 기본으로 제공한다. AppArmor를 지원하지 않는 Amazon Linux와 같은 배포판은 AppArmor와 유사한 접근 방식을 취하는 SELinux를 대신 사용할 수 있다.

애플리케이션의 부하 테스트를 k6를 이용하여 진행하고 결과를 prometheus 및 grafana로 전달하여 확인하는 방법을 작성한다.

k6​

https://github.com/grafana/k6

k6는 오픈소스 부하테스트 도구로, Go와 자바스크립트를 이용해 성능 테스트를 할 수 있는 도구이다. k6은 다양한 프로토콜(HTTP, WebSocket 등)을 지원하며, 설치와 사용이 매우 간편하다. 이전에 k6 테스트를 작성해 본 적이 없다면 Running k6를 확인하고 작동 방식을 파악하는 것부터 시작하는 것이 좋다. 또한, 친철하게 한글로 설명되어 있는 tutorial 링크도 참조한다.

https://github.com/schooldevops/k6-tutorials/blob/main/GettingStarts/01_intro_install.md

kyverno 도구를 이용해서 쿠버네티스의 정책 엔진으로 활용하여 보안을 포함한 다양한 정책을 적용하는 방법을 알아본다.

kyverno​

Kyverno는 그리스어로 "지배하다, 다스리다"의 뜻으로 쿠버네티스 네이티브로 설계된 정책 엔진(policy engine)이다. Kyverno 정책을 활용하여 쿠버네티스 리소스가 정책에 부합하는지 검사하고, 필요하면 리소스를 변경하거나 생성할 수 있다. Kyverno 구조 및 동작 방식을 간단히 정리한다.

OPA Gatekeeper는 독자적인 policy 언어인 Rego를 사용하여 policy를 정의하만 kyverno는 쿠버네티스 리소스로 관리되며 정책을 작성하는 데 새로운 언어가 필요하지 않다. OPA Gatekeeper와 유사하게 pre-defined policy library 를 제공한다.

kOps 환경에 구축한 ArgoCD와 Argo Rollout를 좀더 잘 쓰기 위한 몇가지 내용들을 간단하게 기록용으로 작성하였다.

GitOps​

간단하게만 정리하면, GitOps는 Git 리포지토리를 단일 정보 소스(SSOT,Single Source Of Truth)로 사용하여 인프라를 코드로 제공하는 것이다. GitOps는 인프라 구성을 위해 Git을 버전 제어 시스템으로 사용하는 코드형 인프라 (IaC) 가 진화한 것이라고 생각하면 된다. IaC는 원하는 시스템 상태를 정의하고 시스템의 실제 상태를 추적하여 인프라 관리에 대한 선언적 접근 방식을 따르는 경우가 많다. 그래서 배포에 관련된 모든 것을 선언형 기술서로 작성한다음 Config 레포지토리에서 저장을 하고, 해당 정보와 실제 배포된 환경간의 상태 차이가 발생하지 않도록 유지하는 것을 GitOps 업무 패턴이라고 할 수 있다.

또한 개발자에게 익숙한 Git 기반 워크플로우를 사용하여 애플리케이션 개발에서 배포, 애플리케이션 라이프사이클 관리, 인프라 구성에 이르는 기존 프로세스를 기반으로 확장을 할 수 있다. 애플리케이션 라이프사이클 전반에 걸쳐 모든 변경 사항이 Git 리포지토리에서 추적되고, GitOps는 이러한 변경 사항을 자동으로 인프라에 적용하는 것을 말한다.

이처럼 GitOps의 장점중에 가장 중요한 부분은 신뢰할 수 있는 정보가 공유되고, 인프라 구성하는 모든 변경 사항에 대한 추적과 관리가 가능해진다는 점일 것이다.