티스토리 뷰

728x90
반응형

kubectl 활용 팁

Kubernetes 관련 정보들을 검색하던 중에 kubectl 툴을 좀 더 활용할 수 있는 팁 정보가 있어서 정리해 놓는다.

kubectl 은 쿠버네티스를 운영하기 위한 CLI 도구로 상당히 많은 기능들을 제공하기 때문에 기능들을 다 파악하는 것은 어렵지만 강력한 도구로 활용이 가능하다.

기본적인 사용법에 관련된 것은 Cheatsheet 를 참고하면 된다.

kubectl with Shell Completion

kubectl 은 bash 및 zsh가 내장된 쉘 완성 기능을 제공하기 때문에 명령, 플래그 및 객체를 네임스페이스 또는 파드 이름과 같이 자동 완성으로 사용하는 것이 훨씬 쉽다.

아래의 그림은 실제 자동완성 기능을 제공하도록 설정한 후의 사용법을 보여주는 것이다.

shell completion

원문 에는 kubectl 바이너리 설치부터 설명이 되어 있지만 대부분은 kubernetes 설치환경일 것이므로 자동 완성만 처리하면 된다.

Notes

자동 완성 스크립트는 kubectl에 의해서 생성되므로 프로파일에 설정해서 사용하면 된다. 관련된 정보는 kubectl completion -h 를 확인하면 된다.

On linux, usnig bash

리눅스 bash 환경에서 자동완성 스크립트를 Shell 로 로드 처리는 아래의 명령을 사용하면 된다.

      $ source <(kubectl completion bash)
    

프로파일에 적용하려면 아래의 명령으로 프로파일에 적용해 주면 된다.

      $ echo "source <(kubectl completion bash)" >> ~/.bashrc
    

On MacOS, using bash

맥에서 bash 자동 완성을 수행하려면 아래의 명령으로 자동완성 지원 기능을 먼저 설치해야 한다.

      $ brew install bash-completion
    

Shell에 자동완성 스크립트 로드 처리는 아래의 명령을 사용하면 된다.

      $ source $(brew --prefix)/etc/bash_completion
      $ source <(source <(kubectl completion bash)
    

프로파일에 적용하려면 아래의 명령으로 프로파일에 적용해 주면 된다.

      $ echo "source $(brew --prefix)/etc/bash_completion" >> ~/.bash_profile
      $ echo "source <(kubectl completion bash)" >> ~/.bash_profile
    

Kubernetes 구성 병합

여러 쿠버네티스 클러스들과 상호 작용을 하는 경우라면 쿠버네티스 설정을 병합하는 것이 일반적인 패턴이며 병하해서 사용할 떄 특정 클러스터를 사용하도록 하는 파라미터들을 서술하기 위해 context 개념을 사용한다.

제대로 운영하기에는 복잡하기 때문에 KUBECONFIG 환경 변수를 사용해서 구성 파일을 지정하도록 병합할 수 있다.

만일 병합할 2개의 쿠버네티스 클러스터 (cluster1, cluster2) 가 있다면 각 클러스터별로 정보를 가지는 설정 파일이 다음과 같을 것이므로 이를 개별 파일로 구성하도록 한다.

클러스터 #1 설정

      $ 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
    

클러스터 #2 설정 (#1 에서와 같이 처리해서 사용할 장소에 복사하면 된다)

      $ 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
    

위의 2개 설정을 KUBECONFIG 환경 변수를 통해서 접근할 수 있도록 병합하고 context 지정을 통해서 2개의 클러스터를 동적으로 사용할 수 있다. context 는 클러스터를 인증 및 상호작용하도록 구성을 참조할 수 있는 클러스터, 사용자 및 이름을 설명하는 맴 정보라고 생각하면 된다.

이제 --kubeconfig 플래그를 이용해서 각 파일의 context 정보를 확인할 수 있다.

      $ 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
    

각각의 설정 파일은 하나의 context를 가지기 때문에 서로 충돌하지 않으며, 두 파일을 실제 병합하면 두 개의 Context 가 모두 표시된다.

병합을 위해서 cluster-merge 라는 새로운 파일을 만들고 아래와 같이 처리를 하면 된다.

      $ export KUBECONFIG=cluster-merge:cluster-config:cluster2-config
      $ kubectl config get-contexts
      CURRENT NAME CLUSTER AUTHINFO NAMESPACE
      * cluster1 cluster1 cluster1
      cluster2 cluster2 cluster2
    

병합되는 순서는 지정된 순서대로 처리되고 current-context 는 첫번째 구성 파일에서 지정한 context 가 되기 떄문에 액티브 표시 (*) 가 cluster1 context 를 가르키고 있는 것을 확인할 수 있다.

context 를 2번쨰로 변경하면 정보를 아래와 같이 보여지게 된다.

      $ 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
    

병합에 사용했던 파일을 확인해 보면 아래와 같이 변경된 것을 확인할 수 있다.

      $ cat cluster-merge
      apiVersion: v1
      clusters: []
      contexts: []
      current-context: cluster2
      kind: Config
      preferences: {}
      users: []
    

실제 사용되는 클러스터는 항상 current-context 정보로 확인할 수 있다.

Context는 강력하고 다양한 방법으로 활용 및 병합이 가능하다. 예를 들어 모든 kubectl 명령에 적용될 수 있도록 네임 스페이스를 지정하는 Context 를 만들 수도 있다. (사실 매번 네임스페이스 지정하는 것도 귀찮은 일이다)

      $ 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: []
    

위의 예는 cluster1 에 kube-system 이라는 네임스페이스를 모든 명령에 사용할 수 있도록 context를 구성한 것으로 아래와 같이 context를 지정해서 사용할 수 있다.

      $ 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
    

context 에 네임스페이스가 지정되어 있기 때문에 각 명령 단위로 추가로 지정할 필요가 없다.

Kubernetes API 에 대한 정보 확인

Kubernetes는 API 정보 제공을 위해서 swagger UI 가 통합되어 있다. 따라서 아래의 명령으로 json 문서를 얻을 수도 있다.

      $ kubectl proxy
      $ curl -O 127.0.0.1:8001/swagger.json
    

아니면 직접 http://localhost:8001/api/ 페이지를 통해 정보를 확인할 수도 있다.

만일 json 문서를 활용한다면 jq 툴을 이용해서 활용할 수도 있다.

      $ 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/"
      
    

기타 명령

api-versions 명령은 관리자로 실행되며, RBAC가 활성화된 경우라면 다른 API 세트 정보가 표시될 수 있다.

      $ 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
    

explain 명령은 각 파트에 대한 이해를 위한 기능적인 도움을 제공한다.

      $ kubectl explain
      You must specify the type of resource to explain. Valid resource types include:
      * all
      * certificatesigningrequests (aka 'csr')
      * clusters (valid only 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'
        for
        help and examples.
    

예를 들어 explain deploy 명령을 실행해 보고, deploy 의 좀더 세분화된 객체를 지정해서 정보를 확인할 수도 있다.

      $ 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 for the command is root ('/') in 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.
    

Conclusion

다양한 기능들을 제공하기 때문에 모든 것을 알지도 못하고 정리하는 것도 쉽지는 않지만 다양한 자료들을 확인하면서 유용하다고 생각되는 기능들은 비록 발 번역 수준에 오타, 다른 이해가 있더라도 정리를 해 나갈 예정이다.

현재는 프로젝트를 쉬고 있는 중이지만, 향후 실제 기업에서 운영되는 어플리케이션들을 Containerize 처리와 Kubernetes Cluster에 배포 운영하는 프로젝트를 진행할 예정이기 때문에 좀 더 현실적이고 구체적인 사례들을 정리할 수 있을 것 같다.


References

CHEAT SHEET, CONFIGURAITON MERGE, KUBECTL, KUBERNETES, SHELL COMPLETION, 쿠버네티스
728x90
반응형
댓글
250x250
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함