최윧의 개발 노트 최윧의 개발 노트

Kubernetes Deployment 애플리케이션에 선언적인 업데이트를 제공해주는 리소스 객체 deployment는 애플리케이션의 라이프사이클을 나타낼 수 있게 해준다. 어떤 이미지를 사용할지, 파드의 수, 어떤 식으로 업데이트 되어야 하는지 등 K8s의 객체는 워크로드를 어떻게 관리하고 싶은지에 대해 kubernetes 시스템에게 말하는 방식이다. 객체가 생성된 후, 클러스터는 해당 객체가 존재하도록 하고, 쿠버네티스 클러스터의 desired state를 유지하도록 해준다. 컨테이너화된 애플리케이션을 수동으로 업데이트 하는 것은 시간이 많이 들고 귀찮은 일이다. 다음 버전으로 서비스를 업그레이드 하는 것은, 새로운 버전의 파드를 실행시키고, 오래된 파드를 종료시키고, 그리고 새로운 버전이 제대로 실행..

파드를 관리하기 위한 워크로드 리소스 일반적으로 파드를 직접 생성할 필요 없다. 대신, Deployment 나 Job 과 같은 워크로드 리소스를 이용해서 생성한다. 파드가 상태를 추적할 필요가 있다면 StatefulSet 을 사용하는 것을 고려해보자. k8s 클러스터 내의 파드는 두 가지 주요 방식으로 사용된다. 단일 컨테이너를 실행하는 파드: "one-container-per-Pod" 모델은 가장 흔한 케이스이다. 이 경우, 파드를 단일 컨테이너를 감싸고 있는 wrapper로 생각하면 된다. k8s는 단일 컨테이너를 직접 관리하는게 아니라 컨테이너를 관리한다. 함께 실행해야 하는 여러 컨테이너를 실행하는 파드: 파드는 강하게 결합되고, 리소스를 공유해야하는 여러개의 함께 위치하는 컨테이너로 구성된 애플..

Local ephemeral storage 노드는 뒨단을 locally attached writeable device 혹은 램인 ephemeral storage를 가질 수 있다. "Ephemeral"이라는 것은 지속성에 대한 보장이 없다는 것을 의미한다. 파드는 ephemeral local storage를 임시적인 공간, 캐싱 혹은 로그를 위해 사용한다. kubelet은 파드에 local epmeral storage를 emptyDir 볼륨을 컨테이너에 마운트 함으로서 제공할 수 있다. kubelet은 또한 이러한 종류의 스토리지를 node level container logs, 컨테이너 이미지, 실행되는 컨테이너의 쓰기 가능한 영역으로 사용할 수 있다. Setting requests and limits ..

최근 kube-prometheus-stack을 설치한 후 prometheus 자체의 메모리 할당량을 살펴보려고 했는데, 이상하게 prometheus 컨테이너만 메트릭이 나타나지 않는 현상을 발견했다. 먼저 Kubernetes의 QoS가 뭔지 알아본 후 prometheus 메트릭이 나타나지 않은 이유를 살펴보자. QoS Classes Kubernetes는 QoS를 사용하여 Pod의 evicting과 scheduling을 결정한다. Kubernetes가 Pod를 생성하면 다음 세가지 중 하나의 QoS 클래스를 Pod에 할당하게 된다. Guaranteed Burstable BestEffort Guaranteed 파드 내의 모든 컨테이너는 memory limit과 memory request를 가져야 한다. 파드..

Kubernetes에서 namespaces는 하나의 클러스터 내의 리소스 그룹을 분리하는 메커니즘을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일하지만, 모든 네임스페이스에 걸쳐 유일한 것은 아니다. 네임스페이스 기반 스코핑은 namespace 기반 오브젝트(Deployments, Services, etc)에만 가능하며 클러스터 기반 오브젝트에는 사용할 수 없다. 언제 네임스페이스를 사용해야 할 까? 많은 유저가 여러팀, 프로젝트으로 나뉜 환경에서 사용되는 것이 목적이다. 사용자가 열명 정도로 얼마 안되는 클러스터에서는 네임스페이스를 사용할 필요가 전혀 없다. 네임스페이스가 제공하는 기능들이 필요할 때 사용을 시작해라. 네임스페이스는 이름에 대한 범위를 제공한다. 리소스의 이름은 네임스페이스 내에서..

Kubernetes 배포하면 클러스터를 얻게 된다. Kubernetes 클러스터는 노드라고 불리는 컨테이너화된 애플리케이션을 실행시키는 일련의 워커머신으로 구성되어 있다. 모든 클러스터는 최소 하나의 워커노드를 갖는다. 워커 노드는 애플리케이션 워크로드의 컴포넌트들인 Pod들을 호스트 한다. Control plane은 클러스터 내의 워커 노드와 Pod를 관리한다. 프로덕션 환경에서 control plane은 일반적으로 여러 컴퓨터에 걸쳐 실행되고, 클러스터는 일반적으로 여러 노드를 가지기 때문에 fault-tolerance와 high availability를 제공한다. Control Plane Components control plane의 컴포넌트는 클러스터에 대한 전반적인 결정 뿐만 아니라 (예: 스케..

Custom resources 리소스는 특정한 종류의 API 객체들의 집합을 저장하는 Kubernetes API 내의 엔드포인트이다. 예를 들어, 빌트인 파드 리소스는 파드 객체들을 가지고 있다. Custom resource는 Kubernetes API의 확장으로, 기본 Kubernetes 설치시 반드시 사용할 수 있는 것은 아니다. Custom resource는 특정한 kubernetes 설치의 커스텀화를 나타낸다. 하지만, 많은 핵심 kubernetes functions은 custom resource를 이용하여 만들어지고, kubernetes를 더 모듈화한다. Custom resource는 동적 등록을 통해 실행 중인 클러스터에서 사라졌다 나타났다를 할 수 있고, 클러스터 관리자는 custom res..

도커 소켓이란? Docker socket 파일은 /var/run/docker.sock 에 위치한다. 기본적으로 메인 도커 데몬(프로세스)와 통신하기 위해 사용된다. Docker socket은 Docker API의 진입점이다. 이 소켓은 기본으로 Docker CLI에 의해 도커 커맨드를 실행하기 위해 사용된다. [출처] https://geekflare.com/change-docker-sock-file-path/