[Kubernetes] kubectl 활용팁

<div class="markdown-body"> <h1>kubectl 활용 팁</h1><p>Kubernetes 관련 정보들을 검색하던 중에 <a href="https://kubernetes.io/docs/user-guide/kubectl" target="_blank" rel="external"><code>kubectl</code></a> 툴을 좀 더 활용할 수 있는 팁 정보가 있어서 정리해 놓는다.</p> <p>kubectl 은 쿠버네티스를 운영하기 위한 CLI 도구로 상당히 많은 기능들을 제공하기 때문에 기능들을 다 파악하는 것은 어렵지만 강력한 도구로 활용이 가능하다.</p><p>기본적인 사용법에 관련된 것은 <a href="https://kubernetes.io/docs/user-guide/kubectl-cheatsheet/" target="_blank" rel="external">Cheatsheet</a> 를 참고하면 된다.</p> <h2 id="kubectl-with-shell-completion"> <a class="header-anchor" href="#kubectl-with-shell-completion"/>kubectl with Shell Completion</h2><p>kubectl 은 bash 및 zsh가 내장된 쉘 완성 기능을 제공하기 때문에 명령, 플래그 및 객체를 네임스페이스 또는 파드 이름과 같이 자동 완성으로 사용하는 것이 훨씬 쉽다.</p><p>아래의 그림은 실제 자동완성 기능을 제공하도록 설정한 후의 사용법을 보여주는 것이다.</p><p> <img alt="shell completion" loading="lazy" src="https://s3cr3t.net/completion.gif"><br /> </p><p> <a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/" target="_blank" rel="external">원문</a> 에는 kubectl 바이너리 설치부터 설명이 되어 있지만 대부분은 kubernetes 설치환경일 것이므로 자동 완성만 처리하면 된다.</p> <blockquote> <p> <strong>Notes</strong><br /> </p><p>자동 완성 스크립트는 kubectl에 의해서 생성되므로 프로파일에 설정해서 사용하면 된다. 관련된 정보는 <code>kubectl completion -h</code> 를 확인하면 된다.</p> </blockquote> <h2 id="on-linux-usnig-bash"> <a class="header-anchor" href="#on-linux-usnig-bash"/>On linux, usnig bash</h2><p>리눅스 bash 환경에서 자동완성 스크립트를 Shell 로 로드 처리는 아래의 명령을 사용하면 된다.</p> <pre> $ source <(kubectl completion bash) </pre> <p>프로파일에 적용하려면 아래의 명령으로 프로파일에 적용해 주면 된다.</p> <pre> $ echo "source <(kubectl completion bash)" >> ~/.bashrc </pre> <h2 id="on-macos-using-bash"> <a class="header-anchor" href="#on-macos-using-bash"/>On MacOS, using bash</h2><p>맥에서 bash 자동 완성을 수행하려면 아래의 명령으로 자동완성 지원 기능을 먼저 설치해야 한다.</p> <pre> $ brew install bash-completion </pre><p>Shell에 자동완성 스크립트 로드 처리는 아래의 명령을 사용하면 된다.</p><br /> <pre> $ source $(brew --prefix)/etc/bash_completion $ source <(source <(kubectl completion bash) </pre> <p>프로파일에 적용하려면 아래의 명령으로 프로파일에 적용해 주면 된다.</p><br /> <pre> $ echo "source $(brew --prefix)/etc/bash_completion" >> ~/.bash_profile $ echo "source <(kubectl completion bash)" >> ~/.bash_profile </pre><br /> <h1>Kubernetes 구성 병합</h1><p>여러 쿠버네티스 클러스들과 상호 작용을 하는 경우라면 쿠버네티스 설정을 병합하는 것이 일반적인 패턴이며 병하해서 사용할 떄 특정 클러스터를 사용하도록 하는 파라미터들을 서술하기 위해 context 개념을 사용한다.</p><p>제대로 운영하기에는 복잡하기 때문에 <a href="https://kubernetes.io/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/" target="_blank" rel="external"> <code>KUBECONFIG</code> </a> 환경 변수를 사용해서 구성 파일을 지정하도록 병합할 수 있다.</p><p>만일 병합할 2개의 쿠버네티스 클러스터 (cluster1, cluster2) 가 있다면 각 클러스터별로 정보를 가지는 설정 파일이 다음과 같을 것이므로 이를 개별 파일로 구성하도록 한다.</p><p>클러스터 #1 설정</p><br /> <pre> $ kubectl config view --minify > cluster1-config apiVersion: v1 clusters: - cluster: certificate-authority: cluster1_ca.crt server: https://cluster1 name: cluster1 contexts: - context: cluster: cluster1 user: cluster1 name: cluster1 current-context: cluster1 kind: Config preferences: {} users: - name: cluster1 user: client-certificate: cluster1_apiserver.crt client-key: cluster1_apiserver.key </pre><br /> <p>클러스터 #2 설정 (#1 에서와 같이 처리해서 사용할 장소에 복사하면 된다)</p><br /> <pre> $ cat cluster2-config apiVersion: v1 clusters: - cluster: certificate-authority: cluster2_ca.crt server: https://cluster2 name: cluster2 contexts: - context: cluster: cluster2 user: cluster2 name: cluster2 current-context: cluster2 kind: Config preferences: {} users: - name: cluster2 user: client-certificate: cluster2_apiserver.crt client-key: cluster2_apiserver.key </pre><br /> <p>위의 2개 설정을 <code>KUBECONFIG</code> 환경 변수를 통해서 접근할 수 있도록 병합하고 context 지정을 통해서 2개의 클러스터를 동적으로 사용할 수 있다. context 는 클러스터를 인증 및 상호작용하도록 구성을 참조할 수 있는 클러스터, 사용자 및 이름을 설명하는 맴 정보라고 생각하면 된다.</p><p>이제 <code>--kubeconfig</code> 플래그를 이용해서 각 파일의 context 정보를 확인할 수 있다.</p><br /> <pre> $ kubectl --kubeconfig=cluster1-config config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * cluster1 cluster1 cluster1 $ kubectl --kubeconfig=cluster2-config config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * cluster2 cluster2 cluster2 </pre> <p>각각의 설정 파일은 하나의 context를 가지기 때문에 서로 충돌하지 않으며, 두 파일을 실제 병합하면 두 개의 Context 가 모두 표시된다.</p><p>병합을 위해서 <code>cluster-merge</code> 라는 새로운 파일을 만들고 아래와 같이 처리를 하면 된다.</p><br /> <pre> $ export KUBECONFIG=cluster-merge:cluster-config:cluster2-config $ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * cluster1 cluster1 cluster1 cluster2 cluster2 cluster2 </pre> <p>병합되는 순서는 지정된 순서대로 처리되고 current-context 는 첫번째 구성 파일에서 지정한 context 가 되기 떄문에 액티브 표시 (<code>*</code>) 가 cluster1 context 를 가르키고 있는 것을 확인할 수 있다.</p><p>context 를 2번쨰로 변경하면 정보를 아래와 같이 보여지게 된다.</p><br /> <pre> $ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * cluster1 cluster1 cluster1 cluster2 cluster2 cluster2 $ kubectl config use-context cluster2 Switched to context "cluster2". $ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE cluster1 cluster1 cluster1 * cluster2 cluster2 cluster2 </pre> <p>병합에 사용했던 파일을 확인해 보면 아래와 같이 변경된 것을 확인할 수 있다.</p><br /> <pre> $ cat cluster-merge apiVersion: v1 clusters: [] contexts: [] current-context: cluster2 kind: Config preferences: {} users: [] </pre> <p>실제 사용되는 클러스터는 항상 <code>current-context</code> 정보로 확인할 수 있다.</p><p>Context는 강력하고 다양한 방법으로 활용 및 병합이 가능하다. 예를 들어 모든 kubectl 명령에 적용될 수 있도록 네임 스페이스를 지정하는 Context 를 만들 수도 있다. (사실 매번 네임스페이스 지정하는 것도 귀찮은 일이다)</p><br /> <pre> $ kubectl config set-context cluster1_kube-system --cluster=cluster1 --namespace=kube-system --user=cluster1 Context "cluster1_kube-system" set. $ cat cluster-merge apiVersion: v1 clusters: [] contexts: - context: cluster: cluster1 namespace: kube-system user: cluster1 name: cluster1_kube-system current-context: cluster2 kind: Config preferences: {} users: [] </pre> <p>위의 예는 cluster1 에 <code>kube-system</code> 이라는 네임스페이스를 모든 명령에 사용할 수 있도록 context를 구성한 것으로 아래와 같이 context를 지정해서 사용할 수 있다.</p><br /> <pre> $ kubectl config use-context cluster_kube-system Switched to context "cluster1_kube-system". $ kubectl get pods NAME READY STATUS RESTARTS AGE default-http-backend-fwx3g 1/1 Running 0 28m kube-addon-manager-cluster 1/1 Running 0 28m kube-dns-268032401-snq3h 3/3 Running 0 28m kubernetes-dashboard-b0thj 1/1 Running 0 28m nginx-ingress-controller-b15xz 1/1 Running 0 28m </pre> <p>context 에 네임스페이스가 지정되어 있기 때문에 각 명령 단위로 추가로 지정할 필요가 없다.</p> <h2 id="kubernetes-api-에-대한-정보-확인"> <a class="header-anchor" href="#kubernetes-api-에-대한-정보-확인"/>Kubernetes API 에 대한 정보 확인</h2><p>Kubernetes는 API 정보 제공을 위해서 <code>swagger UI</code> 가 통합되어 있다. 따라서 아래의 명령으로 json 문서를 얻을 수도 있다.</p> <pre> $ kubectl proxy $ curl -O 127.0.0.1:8001/swagger.json </pre> <p>아니면 직접 <a href="http://localhost:8001/api/" target="_blank" rel="external">http://localhost:8001/api/</a> 페이지를 통해 정보를 확인할 수도 있다.</p><p>만일 json 문서를 활용한다면 <a href="https://stedolan.github.io/jq/" target="_blank" rel="external"><br /> <code>jq</code><br /> </a> 툴을 이용해서 활용할 수도 있다.</p><br /> <pre> $ cat swagger.json | jq '.paths | keys[]' "/api/" "/api/v1/" "/api/v1/configmaps" "/api/v1/endpoints" "/api/v1/events" "/api/v1/namespaces" "/api/v1/nodes" "/api/v1/persistentvolumeclaims" "/api/v1/persistentvolumes" "/api/v1/pods" "/api/v1/podtemplates" "/api/v1/replicationcontrollers" "/api/v1/resourcequotas" "/api/v1/secrets" "/api/v1/serviceaccounts" "/api/v1/services" "/apis/" "/apis/apps/" "/apis/apps/v1beta1/" "/apis/apps/v1beta1/statefulsets" "/apis/autoscaling/" "/apis/batch/" "/apis/certificates.k8s.io/" "/apis/extensions/" "/apis/extensions/v1beta1/" "/apis/extensions/v1beta1/daemonsets" "/apis/extensions/v1beta1/deployments" "/apis/extensions/v1beta1/horizontalpodautoscalers" "/apis/extensions/v1beta1/ingresses" "/apis/extensions/v1beta1/jobs" "/apis/extensions/v1beta1/networkpolicies" "/apis/extensions/v1beta1/replicasets" "/apis/extensions/v1beta1/thirdpartyresources" "/apis/policy/" "/apis/policy/v1beta1/poddisruptionbudgets" "/apis/rbac.authorization.k8s.io/" "/apis/storage.k8s.io/" "/logs/" "/version/" </pre> <h2 id="기타-명령"> <a class="header-anchor" href="#기타-명령"/>기타 명령</h2><p> <code>api-versions</code> 명령은 관리자로 실행되며, RBAC가 활성화된 경우라면 다른 API 세트 정보가 표시될 수 있다.</p><br /> <pre> $ kubectl api-versions apps/v1beta1 authentication.k8s.io/v1beta1 authorization.k8s.io/v1beta1 autoscaling/v1 batch/v1 batch/v2alpha1 certificates.k8s.io/v1alpha1 coreos.com/v1 etcd.coreos.com/v1beta1 extensions/v1beta1 oidc.coreos.com/v1 policy/v1beta1 rbac.authorization.k8s.io/v1alpha1 storage.k8s.io/v1beta1 v1 </pre> <p> <code>explain</code> 명령은 각 파트에 대한 이해를 위한 기능적인 도움을 제공한다.</p><br /> <pre> $ kubectl explain You must specify the type of resource to explain. Valid resource types include: * all * certificatesigningrequests (aka 'csr') * clusters (valid only <span class="keyword">for federation apiservers) * clusterrolebindings * clusterroles * componentstatuses (aka 'cs') * configmaps (aka 'cm') * daemonsets (aka 'ds') * deployments (aka 'deploy') * endpoints (aka 'ep') * events (aka 'ev') * horizontalpodautoscalers (aka 'hpa') * ingresses (aka 'ing') * jobs * limitranges (aka 'limits') * namespaces (aka 'ns') * networkpolicies * nodes (aka 'no') * persistentvolumeclaims (aka 'pvc') * persistentvolumes (aka 'pv') * pods (aka 'po') * poddisruptionbudgets (aka 'pdb') * podsecuritypolicies (aka 'psp') * podtemplates * replicasets (aka 'rs') * replicationcontrollers (aka 'rc') * resourcequotas (aka 'quota') * rolebindings * roles * secrets * serviceaccounts (aka 'sa') * services (aka 'svc') * statefulsets * storageclasses * thirdpartyresources error: Required resource not specified. See 'kubectl explain -h' <span class="keyword">for help and examples. </pre> <p>예를 들어 <code>explain deploy</code> 명령을 실행해 보고, deploy 의 좀더 세분화된 객체를 지정해서 정보를 확인할 수도 있다.</p><br /> <pre> $ kubectl explain deploy.spec.template.spec.containers.livenessProbe.exec RESOURCE: exec <Object> DESCRIPTION: One and only one of the following should be specified. Exec specifies the action to take. ExecAction describes a "run in container" action. FIELDS: command <[]string> Command is the command line to execute inside the container, the working directory <span class="keyword">for</span> the command is root ('/') <span class="keyword">in</span> the container's filesystem. The command is simply exec'd, it is not run inside a shell, so traditional shell instructions ('|', etc) won't work. To use a shell, you need to explicitly call out to that shell. Exit status of 0 is treated as live/healthy and non-zero is unhealthy. </pre> <h2 id="conclusion"> <a class="header-anchor" href="#conclusion"/>Conclusion</h2><p>다양한 기능들을 제공하기 때문에 모든 것을 알지도 못하고 정리하는 것도 쉽지는 않지만 다양한 자료들을 확인하면서 유용하다고 생각되는 기능들은 비록 발 번역 수준에 오타, 다른 이해가 있더라도 정리를 해 나갈 예정이다.</p><p>현재는 프로젝트를 쉬고 있는 중이지만, 향후 실제 기업에서 운영되는 어플리케이션들을 Containerize 처리와 Kubernetes Cluster에 배포 운영하는 프로젝트를 진행할 예정이기 때문에 좀 더 현실적이고 구체적인 사례들을 정리할 수 있을 것 같다.</p> <hr> <p>References</p> <ul> <li> <a href="https://coreos.com/blog/kubectl-tips-and-tricks" target="_blank" rel="external">https://coreos.com/blog/kubectl-tips-and-tricks</a><br /> </li> <li> <a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/" target="_blank" rel="external">https://kubernetes.io/docs/tasks/tools/install-kubectl/</a><br /> </li> </ul> </div>