Passwd

개요 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는 사용할 컴퓨팅 자원이 없어 동작할 수 없게 된다. 이런 경우 리소스쿼터를 사용해 네임스페이스별로 사용할 수 있는 자원량을 제한하는 방법으로 서비스 장애를 예방할 수 있다. 동작 방식 쿠버네티스 관..

개요 사용하고 있는 AWS EKS의 Kubernetes 1.24 버전이 2024년 1월에 EOS 될 예정이라 버전 업그레이드가 필요한 상황이다. 따라서 업그레이드 작업 전 테스트 클러스터에서 서비스가 정상적으로 동작하는지 검증하는 과정을 진행하고 있다. 그중 Jenkins Pipeline이 정상적으로 동작하지 않았던 내용을 기록해 둔다. 현상 운영 환경에서 정상적으로 동작하는 Pipeline을 복사하여 빌드하면 아래와 같은 출력과 함께 장시간 대기한다. Pipeline은 kubernetes Agent에서 동작하도록 구성되어 있어 실행하면 Pipeline 동작을 위한 Pod가 생성되어야 했는데 Pod도 생성이 되지 않았다. 달리 확인할 부분이 없어 Jenkins 포드의 Jenkins 컨테이너 로그를 확인해..

개요 정기적으로 수행하는 작업을 위한 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가 필요하다. 기존 설정 기존 환..

개요 2022.05.16 - [Jenkins] LDAP 연동으로 Jenkins에 LDAP 적용을 했었는데, 이번에는 인증서를 이용한 LDAPS 적용이 필요해 방법을 정리한다. 쿠버네티스 클러스터에 Helm으로 설치한 Jenkins로, 사용한 Chart는 이미 deprecated 된 https://github.com/helm/charts/tree/master/stable/jenkins이다. init container를 이용해 컨테이너 환경 변수로 전달한 인증서를 적용하는 방법으로, https://github.com/helm/charts/issues/23374를 참고하여 진행했다. 적용 방식 1. 공유 공간으로 cacerts-share이라는 이름의 emptyDir volume 생성 2. jenkins 컨테이..

현상 쿠버네티스 클러스터 내 리소스를 모니터링하기 위해 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..

개요 2023.01.28 - [k8s] 현재 사용자 전체 권한 확인 - 1에서 쿠버네티스 사용자의 권한 목록을 확인했었다. 이 글에서는 kuectl 플러그인 중 하나인 access-matrix를 이용해 사용자의 권한 목록을 확인해 본다. access-matrix 리소스에 대한 액세스 매트릭스를 보여주는 kubectl 플러그인이다. kubectl auth can-i --list와 유사하게 현재 사용자의 리소스에 대한 액세스 권한을 나열하되, 사람이 읽기 편한 표 형식으로 출력해 준다. 쿠버네티스 클러스터 관리자가 아닌 일반 사용자가 수행할 수 있는 작업을 확인할 때 유용하게 사용할 수 있다. 설치 Krew 또는 소스로 설치할 수 있다. Krew kubectl krew install access-matrix..