Passwd

HPA (HorizontalPodAutoscaler) Kubernetes에서 HorizontalPodAutoscaler는 Deployment나 ReplicaSet의 리소스 수요에 맞춰 Pod의 수를 자동으로 Scale-up/down 하는 기능을 제공한다. 보통 컴퓨팅 리소스를 추가로 확보할 때는 더 많은 리소스가 있는 자원을 사용하거나, 적당한 리소스가 있는 자원을 여러 대 사용하는 방법을 사용하는데 HorizontalPodAutoscaler는 후자에 해당한다. 때문에 DaemonSet과 같은 복제본 수를 지정할 수 없는 객체를 대상으로 동작하지 않는다. HorizontalPodAutoscaler는 Kubernetes 리소스와 컨트롤러로 구현되어 있다. 리소스는 컨트롤러의 동작을 지정하고, 컨트롤러는 주..

개요 어떤 레이블을 가진 객체를 확인할 때는 kubectl get -l 옵션으로 조건으로 줄 레이블 키-값을 지정한다. kubectl get pods -l app=web-server 그렿다면 여러 값을 OR 조건으로 주어야 할 때는 어떻게 할 수 있을까? 적절한 방법인지는 모르겠지만 나의 경우에는 다음과 같이 확인하곤 했다. 하지만 최근에 -l 옵션을 이용해 조회하는 방법을 알게 되어 정리한다. -l 'KEY in (VAL1,VAL2)' kubectl 명령으로 특정 레이블 키-값을 가진 객체를 조회하는 -l 옵션을 사용할 때 여러 값 중 하나라도 만족하는 객체를 찾고 싶다면 조회 조건을 아래와 같이 지정하면 된다. kubectl get RESOURCE -l 'KEY in (VAL1,VAl2,VAL3.....

Annotation 2021.08.06 - Labels, Selectors and Annotation에서 간단히 정의했는데 쿠버네티스에서 어노테이션은 키-값 형식으로 객체에 대한 정보를 제공하는 임의의 비식별 메타데이터, 간단히 말해 주석을 의미한다. "metadata": { "annotations": { "key1" : "value1", "key2" : "value2" } } yaml 정의 파일에서 spec.metadata.annotations로 정의한다. 어노테이션으로 지정하는 정보는 다음과 같을 수 있다. 이미지 정보 : 빌드, 릴리즈, 타임스탬프, 릴리즈 아이디, Git 브랜치, 이미지 해시, 레지스트리 주소 등 로깅, 모니터링, 분석 또는 감사 리포지터리에 대한 포인터 디버깅 목적으로 사용하는 ..

개요 Kubernetes 환경에서 서비스를 운영하다 보면 동작하던 Pod가 예기치 않은 문제로 재시작하는 상황이 발생할 수 있다. 다만 기본적으로 컨테이너 공간은 휘발성이기 때문에 로그 저장 공간을 따로 마운트 하지 않았다면 재시작 이후에는 로그를 확인할 수 없었다. 즉, 문제가 생긴 원인을 확인할 수 없었다. 하지만 logs 명령어로 이미 종료된 컨테이너의 로그를 확인하는 방법이 있다는 것을 알게되어 적어둔다. logs -p logs 명령여 -p 옵션을 사용하면 Pod 내 컨테이너의 이전 인스턴스 로그를 확인할 수 있다. kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER] # -f, --follow : 로그를 실시간으로 출력한다. # -p. --previ..

리밋 레인지 LimitRange는 Pod나 PVC 등과 같은 쿠버네티스 객체가 사용할 수 있는 리소스를 제한하는 쿠버네티스 객체다. ResoureQuota와 함께 클러스터 리소스 관리를 위해 사용하며, 네임스페이스 별로 또는 클러스터 단위로 생성할 수 있다. 필요성 쿠버네티스 클러스터에는 여러 네임스페이스가 존재하고, 각 네임스페이스에는 Pod를 포함한 여러 객체가 존재할 수 있다. Pod는 클러스터 내 자원을 사용해서 동작하는데, 클러스터 관리자는 특정 네임스페이스가 클러스터 자원을 독점하지 않도록 ResoureQuota를 이용해 네임스페이스 별로 사용할 수 있는 리소스의 총량을 제한할 수 있다. 하지만 임의의 포드가 네임스페이스에 할당된 리소스를 전부 사용하는 경우, 해당 네임스페이스에서 다른 포드가..

리소스 쿼터 ResourceQuota는 네임스페이스 별로 총 리소스 사용을 제한하는 제약 조건을 제공하는 쿠버네티스 객체다. 유형 별로 네임스페이스 생성할 수 있는 객체의 수와 자원이 사용할 수 있는 리소스의 총량을 제한할 수 있다. 필요성 쿠버네티스 클러스터에는 여러 네임스페이스가 존재하고, 각 네임스페이스에는 Pod를 포함한 여러 객체가 존재할 수 있다. Pod는 클러스터 내 자원을 사용해서 동작하는데, 임의의 네임스페이스에서 동작하는 Pod가 클러스터에서 사용할 수 있는 모든 자원을 사용하면 다른 Pod는 사용할 컴퓨팅 자원이 없어 동작할 수 없게 된다. 이런 경우 리소스쿼터를 사용해 네임스페이스별로 사용할 수 있는 자원량을 제한하는 방법으로 서비스 장애를 예방할 수 있다. 동작 방식 쿠버네티스 관..

개요 정기적으로 수행하는 작업을 위한 Cronjob, 그리고 일반적인 Job은 각각 startingDeadlineSeconds, activeDeadlineSeconds라는 설정을 가지고 있다. 각각의 역할에 혼동이 생겨 개념을 적어둔다. Job - activeDeadlineSeconds 일반적으로 Pod 실패나 컨테이너 오류로 종료되지 않는 한, Job은 중단되지 않고 실행된다. 만약 한 번 실행한 Job이 특정 시간 안에 종료되어야 한다면 activeDeadlineSeconds 지정하면 된다. apiVersion: batch/v1 kind: Job metadata: name: pi-with-timeout spec: backoffLimit: 5 activeDeadlineSeconds: 100 templa..

개요 Pod 컨테이너가 root로 실행되면 안 되는 경우 SecurityContext를 활용하여 프로세스 실행 사용자를 변경할 수 있다. 추가로 root 권한을 획득하지 않게 설정하고 싶다면 allowPrivilegeEscalation 설정 적용을 고려해 볼 수 있다. allowPrivilegeEscalation 프로세스가 부모 프로세스보다 많은 권한을 얻을 수 있는지에 대한 부분을 제어한다. 컨테이너 프로세스에 설정되는 no_new_prives 플래그를 직접 제어한다. allowPrivilegeEscalation는 privileged 모드로 실행되거나 CAP_SYS_ADMIN을 가지고 있으면 항상 참이다. allowPrivilegeEscalation과 uid, privileged/CAP_SYS_ADMI..

개요 최근 kubernetes 버전을 1.21에서 1.24로 업그레이드를 진행하게 되면서 쿠버네티스 환경에서 동작하고 있던 helm chart의 업그레이드가 필요해졌다. 관련해서 업그레이드가 필요한 helm chart 중 하나가 JupyterHub였는데, 작업 중 singleuser notebook server 스폰 시 volume 설정 방법을 변경하게 되어 적어둔다. 우선 jupyterhub는 다음과 같은 방식으로 사용 중이다. - kubernetes 환경에서 동작한다. - singleuser server를 spawn 하여 사용한다. - spawn 할 수 있는 여러 profile을 지원한다. - singleuser server는 사용자 별 홈 디렉터리와 nas mount가 필요하다. 기존 설정 기존 환..

현상 쿠버네티스 클러스터 내 리소스를 모니터링하기 위해 kube-prometheus-stack helm chart로 Grafana와 Prometheus를 설치해서 사용하고 있다. 다만 설치한 helm-release의 설정 변경이 필요해, 운영 환경에 적용하기 전에 테스트를 하고자 별도의 네임스페이스에 kube-prometheus-stack chart를 다른 helm-release로 설치했다. helm-release는 정상적으로 설치되었으나 다음과 같이 node_export pod가 pending 상태로 머물러 있는 것을 확인했다. 원인 node-exporter를 describe 명령으로 살펴보면 Events 항목에 아래와 같은 메시지를 확인할 수 있다. node(s) didn't have free por..