Passwd

개요 Kubernetes에서 작업하는 사용자(User)와 서비스 계정(Service Accounts)은 Role-based access control(RBAC)에 의해 클러스터 내 리소스 접근을 제어받는다. Kubernetes 클러스터 관리자는 RoleBinding을 생성하여 User, Group, ServiceAccount에게 권한이 부여된 Role을 연결할 수 있는데, 이때 Group은 User의 집합을 의미한다. 2022.09.07 - [k8s] 인증서 기반 User 생성에서는 단순 User를 생성해 보았는데, 이 글에서는 특정 Group에 속한 User를 생성해 볼 것이다. 기본적으로 OpenSSL을 사용하여 CSR을 생성하는 것은 동일하다. + 인증서를 생성하는 도구로 꼭 OpenSSL을 사용할..

개요 kubernetes에서 사용이 끝난 PVC가 삭제되면 PVC가 사용 중이던 PV는 초기화(reclaim)하는 과정을 거친다. 초기화 정책은 3가지가 존재한다. Retain PVC가 삭제되면 PV를 Released 상태로 만들어 PV를 보존한다. PV 내 데이터는 유지되지만 PV를 재사용할 수 없다. PV에 연결되어 있던 외부 스토리지 볼륨을 삭제하려면 관리자가 작업해야 한다. 또한 볼륨을 재사용하기 위해서는 해당 볼륨을 이용하는 PV를 재생성하는 등의 작업이 필요하다. Delete PV 및 연결되어 있던 외부 스토리지 볼륨을 삭제한다. 동적 프로비저닝으로 생성된 PV는 Delete가 기본값이다. Recycle Reclaiming 시 새 PVC에서 사용할 수 있는 상태로 만든다. 과정 중 PV 내 데..

개요 2022.01.06 - RBAC에서 사용자가 특정 리소스에 대한 권한을 확인할 수 있는 can-i 명령을 살펴보았었다. 다만 현재 사용자에게 부여된 권한 전체를 확인할 필요성이 있어 추가로 정리한다. 사용자 권한 목록 확인 can-i 명령의 --list 옵션은 허용된 모든 action을 출력한다. 다만 --all-namespaces 옵션을 지원하지 않아 네임스페이스 별로 확인해야 한다. kubectl auth can-i --list 모든 권한을 부여받았는지 여부 can-i 명령에서 *는 모든 리소스 또는 모든 verb를 의미한다. 따라서 아래와 같은 방식으로 모든 리소스에 대한 모든 권한이 부여되어 있는지 확인할 수 있다. # 현재 네임스페이스 kubectl auth can-i '*' '*' # 모..

개요 kubeadm으로 구성한 쿠버네티스 클러스터에서 특정 노드를 제외하려고 한다. 방법을 정리해둔다. kubectl로 작업 1. Node 상태 확인 kubectl get nodes 2. Node 스케쥴링 비활성화 Node에 Pod가 스케쥴링되지 않도록 상태를 변경한다. kubectl drain # --ignore-daemonsets : drain 시 daemonset에 의한 pod 제외 Daemonset에 의해 생성된 Pod가 동작 중인 경우에는 --ignore-daemonsets 옵션을 사용하여 실행한다. 참고 : 2022.06.23 - [k8s] drain 3. 노드 삭제 kubectl delete nodes 제거한 노드에서 작업 1. kubeadm reset kubeadm reset은 kubead..

kubectl config 사용자는 쿠버네티스 클러스터를 조작하기 위해 apiserver에 작업을 요청한다. 이때 curl 명령으로도 요청할 수 있으나 key, cert, cacert를 매번 지정해주어야 하는 불편함이 있어 kubeconfig 파일에 해당 정보를 설정해두고 kubectl 명령어로 요청하게 된다. kubectl config 명령은 kubeconfig 파일을 수정한다. 관련 명령어를 통해 2022.09.07 - [k8s] 인증서 기반 User 생성 에서 생성한 user를 추가하고, user가 kubectl을 통해 클러스터를 조작할 수 있도록 설정해보도록 한다. 등록된 정보 확인 kubeconfig에 등록된 사용자, 클러스터, context 정보는 get-* 명령으로 확인할 수 있다. 💡 co..

User vs Service Account 쿠버네티스에서 일반 사용자(Human User)와 Service Account라는 두 종류의 사용자가 존재한다. 일반 사용자 : 쿠버네티스 클러스터 외부에서 쿠버네티스 클러스터를 조작하는 사용자. 클러스터 관리자 입장에서의 사용자에 해당한다. Service Account : 쿠버네티스 내부에서 관리되는, Pod가 쿠버네티스 API를 조작할 때 사용한다. 개발자 입장에서의 사용자에 해당한다. 그리고 사용자는 RBAC에 의해서 클러스터를 조작할 권한을 부여받는데, 이 글에서는 일반 사용자를 생성하는 방법을 정리해둔다. API 인증 방법 쿠버네티스는 사용자 인증을 위해 아래와 같은 방법을 지원한다. Service Account Token 정적 Token Passwor..

개요 2022.09.05 - [kubeadm/cri-dockerd] Kubernetes 설치 / 클러스터 생성 에서 생성한 단일 노드 클러스터에 노드를 추가하고자 한다. kubeadm join node join 시에는 apiserver 주소, token 그리고 인증서 정보가 필요하다. join 명령은 join할 노드에서 실행하면 된다. master와 마찬가지로 container runtime, kubectl, kubeadm, kubelet은 설치되어 있어야 한다. kubeadm join : --token --discovery-token-ca-cert-hash sha256: # 예시 kubeadm join 172.31.29.238:6443 --token kglces.6gw78mgmpybtvtpz \ --d..

개요 이 글에서는 kubeadm으로 클러스터를 생성하고, 컨테이너 엔진/런타임은 docker/cri-dockerd를 사용할 것이다. 설치 환경은 아래와 같다. AWS EC2 Ubuntu 20.04 LTS arm64 RAM >= 2GiB , CPU >= 2 core 참고로 master(controlplane)까지만 세팅할 것이다. master/worker 설정 및 패키지 설치 아래 과정은 master(controlplane), node 모두 설정해두어야 한다. 1. iptables가 bridge 된 트래픽을 보도록 설정 # br_netfilter 모듈 로드 cat

Events 쿠버네티스 리소스 타입 중 하나로 다른 리소스의 상태 변화, 에러 등 시스템에 특정 메시지를 전파해야 할 때 자동으로 만들어진다. 쿠버네티스 클러스터를 개발하고 운영하면서 디버깅할 때 유용하다. Events 조회 Events 리소스에 대해 알지 못해도 한 번쯤은 이미 봤을 텐데, describe 명령어로 확인할 수 있기 때문이다. Events 항목에 나열된 목록이 바로 Events 리소스에 해당한다. 다른 리소스와 마찬가지로 get 명령으로도 조회할 수 있다. kubectl get events --field-selector 옵션을 사용하면 원하는 정보만을 찾아볼 수 있다. # Warning 유형만 확인 kubectl get events --field-selector type=Warning #..

현상 관리하던 쿠버네티스 클러스터에서 Grafana/Prometheus 서비스를 위한 kube-prometheus-stack helm chart를 설치하고 GPU 서버 모니터링을 위해 dcgm-exporter를 함께 설치해서 사용하고 있었다. 다만 최근 몇 가지 이슈가 있어 기존의 kube-prometheus-stack을 완전히 삭제하고 재설치했더니 dcgm-exporter 대시보드에 어떤 메트릭도 보이지 않았다. 프로메테우스에서 관련 메트릭을 수집하는지 확인해봤지만, 마찬가지로 dcgm-exporter가 내보내는 메트릭은 수집되지 않는 상태였다. 환경 환경은 아래와 같다. kubeadm으로 구성한 온프레미스 쿠버네티스 클러스터 kubernetes version 1.17.2 ~ 1.19.0 helm v3..