kubectl을 보다 효과적으로 사용하는 방법: 자세한 가이드

Kubernetes를 사용하는 경우 kubectl은 아마도 가장 많이 사용하는 유틸리티 중 하나일 것입니다. 그리고 특정 도구를 사용하여 작업하는 데 많은 시간을 보낼 때마다 해당 도구를 잘 연구하고 효과적으로 사용하는 방법을 배우는 것이 좋습니다.

팀 Mail.ru의 Kubernetes aaS kubectl을 효과적으로 사용하기 위한 팁과 요령을 찾을 수 있는 Daniel Weibel의 기사를 번역했습니다. 또한 Kubernetes에 대해 더 깊이 이해하는 데 도움이 됩니다.

저자에 따르면 이 기사의 목표는 Kubernetes를 사용하여 일상적인 작업을 더 효율적일 뿐만 아니라 더 즐겁게 만드는 것입니다!

소개: kubectl이란?

kubectl을 보다 효과적으로 사용하는 방법을 배우려면 kubectl이 무엇인지, 어떻게 작동하는지 기본적으로 이해해야 합니다.

사용자 관점에서 kubectl은 Kubernetes 작업을 수행할 수 있는 제어판입니다.

기술적으로 말하면, kubectl은 Kubernetes API 클라이언트입니다.

Kubernetes API는 HTTP REST API입니다. 이 API는 완전히 제어되는 진정한 Kubernetes 사용자 인터페이스입니다. 이는 모든 Kubernetes 작업이 API 엔드포인트로 노출되고 해당 엔드포인트에 대한 HTTP 요청을 통해 이루어질 수 있음을 의미합니다.

따라서 kubectl의 주요 작업은 Kubernetes API에 HTTP 요청을 보내는 것입니다.

Kubernetes는 완전히 리소스 지향적인 시스템입니다. 이는 리소스의 내부 상태를 유지하고 모든 Kubernetes 작업이 CRUD 작업임을 의미합니다.

이러한 리소스를 관리하여 Kubernetes를 완벽하게 제어할 수 있으며, Kubernetes는 리소스의 현재 상태에 따라 수행할 작업을 파악합니다. 이러한 이유로 Kubernetes API 참조는 관련 작업과 함께 리소스 유형 목록으로 구성됩니다.

예를 살펴 보겠습니다..

ReplicaSet 리소스를 생성한다고 가정해 보겠습니다. 이를 수행하려면 파일의 ReplicaSet를 이름으로 설명합니다. replicaset.yaml, 다음 명령을 실행합니다.

$ kubectl create -f replicaset.yaml

그러면 ReplicaSet 리소스가 생성됩니다. 하지만 뒤에서 무슨 일이 일어나는 걸까요?

Kubernetes에는 ReplicaSet 생성 작업이 있습니다. 다른 작업과 마찬가지로 API 엔드포인트로 노출됩니다. 이 작업에 대한 특정 API 엔드포인트는 다음과 같습니다.

POST /apis/apps/v1/namespaces/{namespace}/replicasets

모든 Kubernetes 작업에 대한 API 엔드포인트는 다음에서 찾을 수 있습니다. API 참조 (포함 위의 끝점). 엔드포인트에 실제 요청을 하려면 먼저 API 참조에 나열된 엔드포인트 경로에 API 서버 URL을 추가해야 합니다.

따라서 위 명령을 실행하면 kubectl은 위 API 엔드포인트에 HTTP POST 요청을 보냅니다. 파일에 제공한 ReplicaSet 정의 replicaset.yaml, 요청 본문에 전송됩니다.

이는 Kubernetes 클러스터와 상호 작용하는 모든 명령에 대해 kubectl이 작동하는 방식입니다. 이 모든 경우에 kubectl은 적절한 Kubernetes API 엔드포인트에 HTTP 요청을 보냅니다.

다음과 같은 유틸리티를 사용하여 Kubernetes를 완전히 관리할 수 있습니다. curlKubernetes API에 HTTP 요청을 수동으로 보냅니다. Kubectl을 사용하면 Kubernetes API를 더 쉽게 사용할 수 있습니다.

이것이 kubectl이 무엇인지, 어떻게 작동하는지에 대한 기본 사항입니다. 그러나 모든 kubectl 사용자가 알아야 할 Kubernetes API에 관한 또 다른 사항이 있습니다. Kubernetes의 내부 세계를 간단히 살펴보겠습니다.

Kubernetes의 내부 세계

Kubernetes는 클러스터 노드에서 별도의 프로세스로 실행되는 독립 구성 요소 집합으로 구성됩니다. 일부 구성 요소는 마스터 노드에서 실행되고 다른 구성 요소는 작업자 노드에서 실행되며 각 구성 요소는 고유한 특정 작업을 수행합니다.

기본 노드의 가장 중요한 구성 요소는 다음과 같습니다.

1. 둥근 천장 - 리소스 정의를 저장합니다(일반적으로 etcd입니다).
2. API 서버 — API를 제공하고 스토리지를 관리합니다.
3. 컨트롤러 관리자 — 리소스 상태가 사양을 준수하는지 확인합니다.
4. 스케줄러 — 작업자 노드에서 포드를 예약합니다.

작업자 노드의 가장 중요한 구성 요소는 다음과 같습니다.

1. 쿠벨렛 — 작업 노드에서 컨테이너 시작을 관리합니다.

이러한 구성 요소가 어떻게 함께 작동하는지 이해하기 위해 예를 살펴보겠습니다.

방금 완료했다고 가정 해 보겠습니다. kubectl create -f replicaset.yaml, 그 후 kubectl은 HTTP POST 요청을 수행했습니다. ReplicaSet API 엔드포인트 (ReplicaSet 리소스 정의 전달)

클러스터에서는 무슨 일이 일어나고 있나요?

1. 한 후 kubectl create -f replicaset.yaml API 서버는 ReplicaSet 리소스 정의를 스토리지에 저장합니다.

   

2. 다음으로, ReplicaSet 리소스의 생성, 수정 및 삭제를 처리하는 ReplicaSet 컨트롤러가 컨트롤러 관리자에서 실행됩니다.

   

3. ReplicaSet 컨트롤러는 ReplicaSet 정의의 포드 템플릿에 따라 각 ReplicaSet 복제본에 대한 포드 정의를 생성하고 이를 스토리지에 저장합니다.

   

4. 스케줄러가 시작되어 아직 작업자 노드에 할당되지 않은 Pod를 추적합니다.

   

5. 스케줄러는 각 Pod에 적합한 작업자 노드를 선택하고 이 정보를 저장소의 Pod 정의에 추가합니다.

   

6. Pod가 할당된 작업자 노드에서 Kubelet이 시작되고 이 노드에 할당된 Pod를 추적합니다.

   

7. Kubelet은 스토리지에서 포드 정의를 읽고 Docker와 같은 컨테이너 런타임에 노드에서 컨테이너를 시작하도록 지시합니다.

   

아래는 이 설명의 텍스트 버전입니다.

ReplicaSet 생성 엔드포인트에 대한 API 요청은 API 서버에서 처리됩니다. API 서버는 요청을 인증하고 ReplicaSet 리소스 정의를 스토리지에 저장합니다.

이 이벤트는 컨트롤러 관리자의 하위 프로세스인 ReplicaSet 컨트롤러를 시작합니다. ReplicaSet 컨트롤러는 저장소에서 ReplicaSet 리소스의 생성, 업데이트 및 삭제를 모니터링하고 이러한 일이 발생하면 이벤트 알림을 받습니다.

ReplicaSet 컨트롤러의 임무는 필요한 수의 ReplicaSet 포드가 존재하는지 확인하는 것입니다. 이 예에서는 아직 포드가 없으므로 ReplicaSet 컨트롤러는 이러한 포드 정의를 생성하고(ReplicaSet 정의의 포드 템플릿에 따라) 이를 스토리지에 저장합니다.

새 Pod 생성은 아직 작업자 노드에 대해 예약되지 않은 Pod 정의를 추적하는 스케줄러에 의해 트리거됩니다. 스케줄러는 각 Pod에 적합한 작업자 노드를 선택하고 저장소의 Pod 정의를 업데이트합니다.

이 시점까지는 클러스터 어디에서도 워크로드 코드가 실행되지 않았습니다. 지금까지 한 모든 일은 - 이는 마스터 노드의 저장소에서 리소스를 생성하고 업데이트하는 것입니다.

마지막 이벤트는 작업자 노드에 대해 예약된 Pod를 모니터링하는 Kubelets를 트리거합니다. ReplicaSet Pod가 설치된 작업자 노드의 Kubelet은 Docker와 같은 컨테이너 런타임에 필요한 컨테이너 이미지를 다운로드하고 실행하도록 지시해야 합니다.

이 시점에서 ReplicaSet 애플리케이션이 마침내 실행됩니다!

Kubernetes API의 역할

이전 예에서 본 것처럼 Kubernetes 구성 요소(API 서버 및 스토리지 제외)는 스토리지의 리소스 변경 사항을 감시하고 스토리지의 리소스에 대한 정보를 변경합니다.

물론 이러한 구성 요소는 스토리지와 직접 상호 작용하지 않고 Kubernetes API를 통해서만 상호 작용합니다.

다음 예를 고려하십시오.:

1. ReplicaSet 컨트롤러는 API 엔드포인트를 사용합니다. ReplicaSet 나열 매개변수 포함 watch ReplicaSet 리소스의 변경 사항을 모니터링합니다.
2. ReplicaSet 컨트롤러는 API 엔드포인트를 사용합니다. 포드 생성 (포드 생성) 포드를 생성합니다.
3. 스케줄러는 API 엔드포인트를 사용합니다. 패치 포드 (포드 편집) 선택한 작업자 노드에 대한 정보로 포드를 업데이트합니다.

보시다시피 이는 kubectl이 액세스하는 것과 동일한 API입니다. 내부 구성 요소와 외부 사용자에 동일한 API를 사용하는 것은 Kubernetes 설계의 기본 개념입니다.

이제 Kubernetes의 작동 방식을 요약할 수 있습니다.

1. 스토리지는 상태, 즉 Kubernetes 리소스를 저장합니다.
2. API 서버는 Kubernetes API 형식으로 스토리지에 대한 인터페이스를 제공합니다.
3. 다른 모든 Kubernetes 구성 요소와 사용자는 API를 통해 Kubernetes 상태(리소스)를 읽고 관찰하고 조작합니다.

이러한 개념을 아는 것은 kubectl을 더 잘 이해하고 최대한 활용하는 데 도움이 됩니다.

이제 kubectl을 사용하여 생산성을 향상시키는 데 도움이 되는 몇 가지 구체적인 팁과 요령을 살펴보겠습니다.

1. 명령완성을 이용한 입력속도 향상

kubectl을 사용하여 성능을 향상시키는 가장 유용하지만 종종 간과되는 기술 중 하나는 명령 완성입니다.

명령 완성을 사용하면 Tab 키를 사용하여 kubectl 명령의 일부를 자동으로 완성할 수 있습니다. 이는 리소스 이름과 같은 복잡한 항목을 포함하여 하위 명령, 옵션 및 인수에 대해 작동합니다.

kubectl 명령 완성이 어떻게 작동하는지 확인하세요.

명령 완성은 Bash 및 Zsh 셸에서 작동합니다.

공식 가이드 자동 완성 설정에 대한 자세한 지침이 포함되어 있지만 아래에서는 짧은 발췌 내용을 제공합니다.

명령 완성 작동 방식

명령 완성은 완성 스크립트를 사용하여 작동하는 셸 기능입니다. 확장 스크립트는 특정 명령에 대한 확장 동작을 정의하는 셸 스크립트입니다.

Kubectl은 다음 명령을 사용하여 Bash 및 Zsh용 확장 스크립트를 자동으로 생성하고 출력합니다.

$ kubectl completion bash

Или :

$ kubectl completion zsh

이론적으로는 kubectl이 명령을 보완할 수 있도록 이러한 명령의 출력을 적절한 명령 셸에 연결하는 것으로 충분합니다.

실제로 Bash(Linux와 MacOS의 차이점 포함)와 Zsh의 연결 방법은 다릅니다. 아래에서는 이러한 모든 옵션을 살펴보겠습니다.

리눅스에서의 배쉬

Bash 완성 스크립트는 bash-completion 패키지에 따라 다르므로 먼저 설치해야 합니다.

$ sudo apt-get install bash-completion

Или :

$ yum install bash-completion

다음 명령을 사용하여 패키지가 성공적으로 설치되었는지 테스트할 수 있습니다.

$ type _init_completion

쉘 함수 코드가 출력되면 bash-completion이 올바르게 설치된 것입니다. 명령에서 "찾을 수 없음" 오류가 발생하면 파일에 다음 줄을 추가해야 합니다. ~ / .bashrc:

$ source /usr/share/bash-completion/bash_completion

이 줄을 파일에 추가해야 합니까? ~ / .bashrc bash-completion을 설치하는 데 사용한 패키지 관리자에 따라 다릅니다. 이는 APT에는 필요하지만 YUM에는 필요하지 않습니다.

bash-completion을 설치한 후에는 kubectl 완성 스크립트가 모든 셸 세션에서 활성화되도록 모든 것을 구성해야 합니다.

이를 수행하는 한 가지 방법은 파일에 다음 줄을 추가하는 것입니다. ~ / .bashrc:

source <(kubectl completion bash)

또 다른 방법은 kubectl 확장 스크립트를 디렉터리에 추가하는 것입니다. /etc/bash_completion.d (존재하지 않는 경우 생성):

$ kubectl completion bash >/etc/bash_completion.d/kubectl

카탈로그의 모든 추가 기능 스크립트 /etc/bash_completion.d bash 완성에 자동으로 포함됩니다.

두 옵션 모두 동일하게 적용됩니다.

셸을 다시 시작하면 kubectl 명령 완성이 작동합니다.

MacOS의 배시

MacOS에서는 설정이 좀 더 복잡합니다. 사실 MacOS는 기본적으로 Bash 버전 3.2를 사용하며 kubectl 자동 완성 스크립트에는 Bash 버전 4.1 이상이 필요하며 Bash 3.2에서는 작동하지 않습니다.

MacOS에서 오래된 버전의 Bash를 사용하는 것과 관련된 라이센스 문제가 있습니다. Bash 버전 4는 Apple에서 지원하지 않는 GPLv3에 따라 라이센스가 부여됩니다.

MacOS에서 kubectl 자동 완성을 구성하려면 최신 버전의 Bash를 설치해야 합니다. 업데이트된 Bash를 기본 셸로 설정할 수도 있습니다. 이렇게 하면 나중에 많은 문제를 줄일 수 있습니다. 어렵지 않습니다. 자세한 내용은 기사에 나와 있습니다.MacOS에서 Bash 업데이트".

계속하기 전에 최신 버전의 Bash를 사용하고 있는지 확인하세요(출력을 확인하세요). bash --version).

Bash 완료 스크립트는 프로젝트에 따라 다릅니다. bash 완성이므로 먼저 설치해야 합니다.

다음을 사용하여 bash 완성을 설치할 수 있습니다. 사제:

$ brew install bash-completion@2

여기에 @2 bash-completion 버전 2를 의미합니다. kubectl 자동 완성에는 bash-completion v2가 필요하고 bash-completion v2에는 최소 Bash 버전 4.1이 필요합니다.

명령 출력 brew-install 파일에 추가해야 할 사항을 지정하는 주의 사항 섹션이 포함되어 있습니다. ~/.bash_profile:

export BASH_COMPLETION_COMPAT_DIR=/usr/local/etc/bash_completion.d
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . 
"/usr/local/etc/profile.d/bash_completion.sh"

그러나 다음 줄을 추가하지 않는 것이 좋습니다. ~/.bash_profile, 및 c ~/.bashrc. 이 경우 기본 명령 셸뿐만 아니라 하위 명령 셸에서도 자동 완성을 사용할 수 있습니다.

명령 셸을 다시 시작한 후 다음 명령을 사용하여 설치가 올바른지 확인할 수 있습니다.

$ type _init_completion

출력에 셸 기능이 표시되면 모든 것이 올바르게 구성된 것입니다.

이제 모든 세션에서 kubectl 자동 완성이 활성화되어 있는지 확인해야 합니다.

한 가지 방법은 다음 줄을 추가하는 것입니다. ~/.bashrc:

source <(kubectl completion bash)

두 번째 방법은 폴더에 자동 완성 스크립트를 추가하는 것입니다. /usr/local/etc/bash_completion.d:

$ kubectl completion bash
>/usr/local/etc/bash_completion.d/kubectl

이 방법은 Homebrew를 사용하여 bash 완성을 설치한 경우에만 작동합니다. 이 경우 bash-completion은 이 디렉터리에서 모든 스크립트를 로드합니다.

설치한 경우 Homebrew를 사용하는 kubectl, 자동 완성 스크립트가 자동으로 폴더에 배치되므로 이전 단계를 수행할 필요가 없습니다. /usr/local/etc/bash_completion.d 설치 중. 이 경우 bash-completion을 설치하자마자 kubectl 자동 완성이 작동하기 시작합니다.

결과적으로 이러한 옵션은 모두 동일합니다.

Zsh

Zsh용 자동 완성 스크립트에는 종속성이 필요하지 않습니다. 명령 셸을 로드할 때 이를 활성화하기만 하면 됩니다.

이 작업은 ~/.zshrc 파일:

source <(kubectl completion zsh)

오류가 발생한 경우 not found: compdef 쉘을 다시 시작한 후 내장 기능을 활성화해야 합니다 compdef. 파일 시작 부분에 추가하여 활성화할 수 있습니다. ~/.zshrc 다음 :

autoload -Uz compinit
compinit

2. 리소스 사양을 빠르게 확인하세요

YAML 리소스 정의를 생성할 때 해당 리소스에 대한 필드와 해당 의미를 알아야 합니다. 이 정보를 찾을 수 있는 한 곳은 모든 리소스에 대한 전체 사양이 포함된 API 참조입니다.

하지만 무언가를 검색해야 할 때마다 웹 브라우저로 전환하는 것은 불편합니다. 따라서 kubectl은 다음 명령을 제공합니다. kubectl explain, 터미널에 있는 모든 리소스의 사양을 보여줍니다.

명령 형식은 다음과 같습니다.

$ kubectl explain resource[.field]...

이 명령은 요청된 리소스 또는 필드의 사양을 출력합니다. 표시되는 정보는 API 매뉴얼에 포함된 정보와 동일합니다.

기본적으로 kubectl explain 필드 중첩의 첫 번째 수준만 표시합니다.

어떻게 생겼는지 확인하세요 여기있을 수 있습니다..

옵션을 추가하면 전체 트리를 표시할 수 있습니다. --recursive:

$ kubectl explain deployment.spec --recursive

어떤 리소스가 필요한지 정확히 모르는 경우 다음 명령을 사용하여 해당 리소스를 모두 표시할 수 있습니다.

$ kubectl api-resources

이 명령은 자원 이름을 복수형으로 표시합니다. deployments 대신 deployment. 예를 들어 짧은 이름도 표시됩니다. deploy, 해당 리소스가 있는 경우. 이러한 차이점에 대해 걱정하지 마십시오. 이러한 이름 지정 옵션은 모두 kubectl과 동일합니다. 즉, 다음 중 하나를 사용할 수 있습니다. kubectl explain.

다음 명령은 모두 동일합니다.

$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или        
$ kubectl explain deploy.spec

3. 사용자 정의 열 출력 형식을 사용하십시오.

기본 명령 출력 형식 kubectl get:

$ kubectl get pods
NAME                     READY    STATUS    RESTARTS  AGE
engine-544b6b6467-22qr6   1/1     Running     0       78d
engine-544b6b6467-lw5t8   1/1     Running     0       78d
engine-544b6b6467-tvgmg   1/1     Running     0       78d
web-ui-6db964458-8pdw4    1/1     Running     0       78d

이 형식은 편리하지만 제한된 양의 정보를 포함합니다. 전체 자원 정의 형식과 비교하여 여기에는 몇 가지 필드만 표시됩니다.

이 경우 사용자 정의 열 출력 형식을 사용할 수 있습니다. 이를 통해 출력할 데이터를 결정할 수 있습니다. 모든 자원 필드를 별도의 열로 표시할 수 있습니다.

사용자 정의 형식의 사용은 다음 옵션을 사용하여 결정됩니다.

-o custom-columns=<header>:<jsonpath>[,<header>:<jsonpath>]...

각 출력 열을 쌍으로 정의할 수 있습니다. <header>:<jsonpath>어디에서 <header> 은 열 이름이고, <jsonpath> — 리소스 필드를 정의하는 표현식입니다.

간단한 예를 살펴보겠습니다.

$ kubectl get pods -o custom-columns='NAME:metadata.name'

NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4

출력에는 Pod 이름이 포함된 열 하나가 포함되어 있습니다.

옵션 표현식은 필드에서 포드 이름을 선택합니다. metadata.name. 하위 이름 필드에 Pod 이름이 정의되어 있기 때문입니다. metadata 포드의 리소스 설명에 있습니다. 자세한 내용은 다음에서 확인할 수 있습니다. API 가이드 또는 명령을 입력하십시오 kubectl explain pod.metadata.name.

이제 출력에 추가 열을 추가한다고 가정해 보겠습니다. 예를 들어 각 포드가 실행 중인 노드를 표시합니다. 이렇게 하려면 사용자 정의 열 옵션에 적절한 열 사양을 추가하기만 하면 됩니다.

$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,NODE:spec.nodeName'

NAME                       NODE
engine-544b6b6467-22qr6    ip-10-0-80-67.ec2.internal
engine-544b6b6467-lw5t8    ip-10-0-36-80.ec2.internal
engine-544b6b6467-tvgmg    ip-10-0-118-34.ec2.internal
web-ui-6db964458-8pdw4     ip-10-0-118-34.ec2.internal

표현식은 다음에서 노드 이름을 선택합니다. spec.nodeName — Pod가 노드에 할당되면 해당 이름이 필드에 기록됩니다. spec.nodeName 포드 리소스 사양. 더 자세한 정보는 출력에서 ​​확인할 수 있습니다. kubectl explain pod.spec.nodeName.

Kubernetes 리소스 필드는 대소문자를 구분합니다.

모든 자원 필드를 열로 볼 수 있습니다. 리소스 사양을 검토하고 원하는 필드에 사용해 보세요.

하지만 먼저 필드 선택 표현식을 자세히 살펴보겠습니다.

JSONPath 표현식

자원 필드를 선택하는 표현식은 다음을 기반으로 합니다. JSON경로.

JSONPath는 JSON 문서에서 데이터를 검색하는 언어입니다. 단일 필드를 선택하는 것은 JSONPath의 가장 간단한 사용 사례입니다. 그는 가진 것이 많다 더 많은 가능성, 선택기, 필터 등을 포함합니다.

Kubectl explain은 제한된 수의 JSONPath 기능을 지원합니다. 사용 가능성과 예는 아래에 설명되어 있습니다.

# Выбрать все элементы списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[*].image'
# Выбрать специфический элемент списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[0].image'
# Выбрать элементы списка, попадающие под фильтр
$ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'
# Выбрать все поля по указанному пути, независимо от их имени
$ kubectl get pods -o custom-columns='DATA:metadata.*'
# Выбрать все поля с указанным именем, вне зависимости от их расположения
$ kubectl get pods -o custom-columns='DATA:..image'

[] 연산자는 특히 중요합니다. 많은 Kubernetes 리소스 필드는 목록이며, 이 연산자를 사용하면 해당 목록의 구성원을 선택할 수 있습니다. 목록의 모든 요소를 ​​선택하기 위해 [*]와 같은 와일드카드와 함께 자주 사용됩니다.

적용 사례

출력에 어떤 필드나 자원 필드의 조합도 표시할 수 있으므로 사용자 정의 열 출력 형식을 사용할 수 있는 가능성은 무궁무진합니다. 다음은 몇 가지 샘플 앱입니다. 자유롭게 직접 탐색하고 자신에게 적합한 애플리케이션을 찾아보세요.

1. Pod의 컨테이너 이미지 표시:

   $ kubectl get pods 
     -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'
   
   NAME                        IMAGES
   engine-544b6b6467-22qr6     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-lw5t8     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-tvgmg     rabbitmq:3.7.8-management,nginx
   web-ui-6db964458-8pdw4      wordpress

   이 명령은 각 포드의 컨테이너 이미지 이름을 표시합니다.

   Pod에는 여러 개의 컨테이너가 포함될 수 있으며 이미지 이름은 쉼표로 구분되어 한 줄에 표시됩니다.

2. 노드 가용성 영역 표시:

   $ kubectl get nodes 
     -o 
   custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain.beta.kubernetes.io/zone'
   
   NAME                          ZONE
   ip-10-0-118-34.ec2.internal   us-east-1b
   ip-10-0-36-80.ec2.internal    us-east-1a
   ip-10-0-80-67.ec2.internal    us-east-1b

   이 명령은 클러스터가 퍼블릭 클라우드에서 호스팅되는 경우 유용합니다. 각 노드의 가용성 영역을 표시합니다.

   가용성 영역은 복제 영역을 지리적 지역으로 제한하는 클라우드 개념입니다.

   각 노드의 가용 영역은 특수 라벨을 통해 획득됩니다. failure-domain.beta.kubernetes.io/zone. 클러스터가 퍼블릭 클라우드에서 실행 중인 경우 이 레이블은 자동으로 생성되고 각 노드의 가용성 영역 이름으로 채워집니다.

   라벨은 Kubernetes 리소스 사양의 일부가 아니므로 라벨에 대한 정보를 찾을 수 없습니다. API 가이드. 그러나 YAML 또는 JSON 형식으로 노드에 대한 정보를 요청하면 다른 라벨과 마찬가지로 표시될 수 있습니다.

   $ kubectl get nodes -o yaml
   # или
   $ kubectl get nodes -o json

   이는 리소스 사양을 배우는 것 외에도 리소스에 대해 자세히 알아볼 수 있는 좋은 방법입니다.

4. 클러스터와 네임스페이스 간을 쉽게 전환합니다.

kubectl이 Kubernetes API에 요청할 때 먼저 kubeconfig 파일을 읽어 연결에 필요한 모든 매개변수를 가져옵니다.

기본적으로 kubeconfig 파일은 다음과 같습니다. ~/.kube/config. 일반적으로 이 파일은 특수 명령으로 생성되거나 업데이트됩니다.

여러 클러스터로 작업할 때 kubeconfig 파일에는 모든 클러스터에 연결하기 위한 설정이 포함되어 있습니다. 작업 중인 클러스터를 kubectl 명령에 알려주는 방법이 필요합니다.

클러스터 내에서 여러 네임스페이스(물리적 클러스터 내의 가상 클러스터 유형)를 생성할 수 있습니다. Kubectl은 또한 kubeconfig 파일을 기반으로 사용할 네임스페이스를 결정합니다. 이는 kubectl 명령에 어떤 네임스페이스를 사용할지 알려줄 방법도 필요하다는 것을 의미합니다.

이번 장에서는 이것이 어떻게 작동하는지, 어떻게 효과적으로 작동하게 만드는지에 대해 설명하겠습니다.

KUBECONFIG 환경 변수에 여러 개의 kubeconfig 파일이 나열되어 있을 수 있습니다. 이 경우 이러한 모든 파일은 런타임 시 하나의 공통 구성으로 결합됩니다. 매개변수로 kubectl을 실행하여 기본 kubeconfig 파일을 변경할 수도 있습니다. --kubeconfig. 보다 공식 문서.

kubeconfig 파일

kubeconfig 파일에 정확히 무엇이 포함되어 있는지 살펴보겠습니다.

보시다시피 kubeconfig 파일에는 일련의 컨텍스트가 포함되어 있습니다. 컨텍스트는 세 가지 요소로 구성됩니다.

• 클러스터 — 클러스터 서버의 API URL입니다.
• 사용자 - 클러스터의 사용자 인증 자격 증명입니다.
• 네임스페이스 - 클러스터에 참가할 때 사용되는 네임스페이스입니다.

실제로는 kubeconfig에서 클러스터당 하나의 컨텍스트를 사용하는 경우가 많습니다. 그러나 사용자 또는 네임스페이스로 구별되는 클러스터당 여러 컨텍스트를 가질 수 있습니다. 그러나 이러한 다중 컨텍스트 구성은 일반적이지 않으므로 일반적으로 클러스터와 컨텍스트 간에 일대일 매핑이 있습니다.

언제든지 컨텍스트 중 하나가 현재 상태입니다.

kubectl은 구성 파일을 읽을 때 항상 현재 컨텍스트에서 정보를 가져옵니다. 위의 예에서 kubectl은 Hare 클러스터에 연결됩니다.

따라서 다른 클러스터로 전환하려면 kubeconfig 파일에서 현재 컨텍스트를 변경해야 합니다.

이제 kubectl이 Fox 클러스터에 연결됩니다.

동일한 클러스터의 다른 네임스페이스로 전환하려면 현재 컨텍스트에 대한 네임스페이스 요소의 값을 변경해야 합니다.

위의 예에서 kubectl은 Fox 클러스터의 Prod 네임스페이스(이전에 Test 네임스페이스가 설정됨)를 사용합니다.

kubectl은 옵션도 제공합니다. --cluster, --user, --namespace и --context, kubeconfig에 설정된 내용에 관계없이 개별 요소와 현재 컨텍스트 자체를 덮어쓸 수 있습니다. 바라보다 kubectl options.

이론적으로는 kubeconfig에서 설정을 수동으로 변경할 수 있습니다. 하지만 불편해요. 이러한 작업을 단순화하기 위해 매개변수를 자동으로 변경할 수 있는 다양한 유틸리티가 있습니다.

kubectx 사용

클러스터와 네임스페이스 간 전환에 매우 널리 사용되는 유틸리티입니다.

유틸리티는 명령을 제공합니다 kubectx и kubens 현재 컨텍스트와 네임스페이스를 각각 변경합니다.

앞서 언급했듯이 현재 컨텍스트를 변경한다는 것은 클러스터당 하나의 컨텍스트만 있는 경우 클러스터를 변경하는 것을 의미합니다.

다음은 이러한 명령을 실행하는 예입니다.

기본적으로 이러한 명령은 위에서 설명한 대로 kubeconfig 파일을 편집합니다.

설치하기 위해서 kubectx, 다음 지침을 따르세요. 기둥.

두 명령 모두 컨텍스트 및 네임스페이스 이름의 자동 완성을 지원하므로 이름을 완전히 입력할 필요가 없습니다. 자동 완성 설정 지침 여기에.

또 다른 유용한 기능 kubectx 이 대화형 모드. 유틸리티와 함께 ​​작동합니다. fzf, 별도로 설치해야 합니다. fzf를 설치하면 자동으로 대화형 모드를 사용할 수 있습니다. kubectx. fzf에서 제공하는 대화형 무료 검색 인터페이스를 통해 대화형으로 컨텍스트와 네임스페이스를 선택할 수 있습니다.

쉘 별칭 사용

kubectl은 이를 위한 명령도 제공하므로 현재 컨텍스트와 네임스페이스를 변경하는 데 별도의 도구가 필요하지 않습니다. 응, 팀 kubectl config kubeconfig 파일을 편집하기 위한 하위 명령을 제공합니다.

다음은 그 중 일부입니다.

• kubectl config get-contexts: 모든 컨텍스트를 표시합니다.
• kubectl config current-context: 현재 컨텍스트를 가져옵니다.
• kubectl config use-context: 현재 컨텍스트를 변경합니다.
• kubectl config set-context: 컨텍스트 요소를 변경합니다.

그러나 이러한 명령을 직접 사용하는 것은 길이가 길기 때문에 그다지 편리하지 않습니다. 실행하기 쉬운 쉘 별칭을 만들 수 있습니다.

kubectx와 유사한 기능을 제공하는 이러한 명령을 기반으로 별칭 세트를 만들었습니다. 여기에서 실제로 작동하는 모습을 볼 수 있습니다.

별칭은 fzf를 사용하여 대화형 무료 조회 인터페이스(예: kubectx의 대화형 모드)를 제공합니다. 이것은 당신이 필요하다는 것을 의미합니다 fzf 설치이러한 별칭을 사용합니다.

별칭 자체의 정의는 다음과 같습니다.

# Получить текущий контекст
alias krc='kubectl config current-context'
# Список всех контекстов
alias klc='kubectl config get-contexts -o name | sed "s/^/  /;|^  $(krc)$|s/ /*/"'
# Изменить текущий контекст
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'

# Получить текущее пространство имен
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print $5}" | sed "s/^$/default/"'
# Список всех пространств имен
alias kln='kubectl get -o name ns | sed "s|^.*/|  |;|^  $(krn)$|s/ /*/"'
# Изменить текущее пространство имен
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

이러한 별칭을 설정하려면 위의 정의를 파일에 추가해야 합니다. ~/.bashrc 또는 ~/.zshrc 쉘을 재부팅하십시오.

플러그인 사용

Kubectl을 사용하면 기본 명령과 동일한 방식으로 실행되는 플러그인을 로드할 수 있습니다. 예를 들어 kubectl-foo 플러그인을 설치하고 다음 명령을 실행하여 실행할 수 있습니다. kubectl foo.

예를 들어 다음을 실행하여 컨텍스트와 네임스페이스를 변경하는 것이 편리할 것입니다. kubectl ctx 상황을 바꾸고 kubectl ns 네임스페이스를 변경합니다.

나는 이 작업을 수행하는 두 개의 플러그인을 작성했습니다.

• kubectl-ctx
• kubectl-ns

플러그인 작업은 이전 섹션의 별칭을 기반으로 합니다.

작동 방식은 다음과 같습니다.

플러그인은 fzf를 사용하여 대화형 무료 검색 인터페이스(예: kubectx의 대화형 모드)를 제공합니다. 이것은 당신이 필요하다는 것을 의미합니다 fzf 설치이러한 별칭을 사용합니다.

플러그인을 설치하려면 다음과 같은 쉘 스크립트를 다운로드해야 합니다. kubectl-ctx и kubectl-ns PATH 변수의 임의의 디렉토리에 복사하고 예를 들어 실행 가능하게 만듭니다. chmod +x. 이 후 즉시 사용할 수 있습니다. kubectl ctx и kubectl ns.

5. 자동 별칭으로 입력 줄이기

쉘 별명은 입력 속도를 높이는 좋은 방법입니다. 프로젝트 kubectl 별칭 기본 kubectl 명령에 대한 약 800개의 단축키가 포함되어 있습니다.

800개의 별칭을 어떻게 기억하시나요? 하지만 아래에 제시된 간단한 구성에 따라 구축되었기 때문에 모두 기억할 필요는 없습니다.

예를 들면 다음과 같습니다

1. kgpooyaml - kubectl이 포드 oyaml 가져오기
2. ksysgsvcw — kubectl -n kube-system svc w 가져오기
3. ksysrmcm -kubectl -n kube-system rm cm
4. kgdepallsl - kubectl은 모든 sl 배포를 가져옵니다.

보시다시피 별칭은 구성 요소로 구성되며 각 구성 요소는 kubectl 명령의 특정 요소를 나타냅니다. 각 별칭에는 기본 명령, 작업 및 리소스에 대한 하나의 구성 요소와 매개 변수에 대한 여러 구성 요소가 있을 수 있습니다. 위 다이어그램에 따라 이러한 구성 요소를 왼쪽에서 오른쪽으로 간단히 "채우기"만 하면 됩니다.

현재 세부 다이어그램은 다음과 같습니다. GitHub의. 거기에서도 찾을 수 있어요 별칭의 전체 목록.

예를 들어 별칭 kgpooyamlall은 다음 명령과 동일합니다. kubectl get pods -o yaml --all-namespaces.

옵션의 상대적 순서는 중요하지 않습니다. kgpooyamlall 명령과 동일합니다 kgpoalloyaml.

모든 구성 요소를 별칭으로 사용할 필요는 없습니다. 예를 들어 k, kg, klo, ksys, kgpo 또한 사용할 수 있습니다. 또한 명령줄에서 별칭과 일반 명령 또는 옵션을 결합할 수 있습니다.

예를 들면 다음과 같습니다

1. 대신에 kubectl proxy 당신은 쓸 수 있습니다 k proxy.
2. 대신에 kubectl get roles 당신은 쓸 수 있습니다 kg roles (현재 역할 리소스에 대한 별칭은 없습니다).
3. 특정 포드에 대한 데이터를 얻으려면 다음 명령을 사용할 수 있습니다. kgpo my-pod — kubectl get pod my-pod.

일부 별칭에는 명령줄 인수가 필요합니다. 예를 들어 별칭 kgpol 방법 kubectl get pods -l. 옵션 -l 인수(레이블 사양)가 필요합니다. 별칭을 사용하면 다음과 같습니다. kgpol app=ui.

일부 별칭에는 인수가 필요하므로 별칭 a, f 및 l을 마지막에 사용해야 합니다.

일반적으로 이 구성표를 익히면 실행하려는 명령에서 직관적으로 별칭을 파생할 수 있어 입력 시간을 많이 절약할 수 있습니다.

설치

kubectl-aliases를 설치하려면 파일을 다운로드해야 합니다. .kubectl_aliases GitHub에서 파일에 포함 ~/.bashrc 또는 ~/.zshrc:

source ~/.kubectl_aliases

자동 완성

이전에 말했듯이 명령줄에서 별칭에 추가 단어를 추가하는 경우가 많습니다. 예를 들어:

$ kgpooyaml test-pod-d4b77b989

kubectl 명령 완성을 사용하는 경우 리소스 이름과 같은 항목에 대해 자동 완성을 사용했을 것입니다. 그러나 별칭을 사용할 때 이것이 가능합니까?

자동 완성이 작동하지 않으면 별칭의 이점 중 일부를 잃게 되므로 이는 매우 중요한 질문입니다.

대답은 사용 중인 쉘에 따라 다릅니다.

1. Zsh의 경우 별칭 완성 기능이 즉시 작동합니다.
2. 불행하게도 Bash의 경우 자동 완성이 작동하려면 일부 작업이 필요합니다.

Bash에서 별칭 자동 완성 활성화

Bash의 문제점은 별칭이 참조하는 명령(예를 들어 Zsh가 수행하는 것처럼)이 아니라 별칭을 완성하려고 시도한다는 것입니다(Tab을 누를 때마다). 800개 별칭 모두에 대한 완성 스크립트가 없기 때문에 자동 완성이 작동하지 않습니다.

계획 완전한 별칭 이 문제에 대한 일반적인 솔루션을 제공합니다. 별칭의 완성 메커니즘에 연결하고, 내부적으로 별칭을 명령으로 확장하고, 완료된 명령에 대한 완성 옵션을 반환합니다. 이는 별명에 대한 패딩이 전체 명령의 경우와 정확히 동일하게 작동함을 의미합니다.

다음에서는 먼저 완전한 별칭을 설치하는 방법과 모든 kubectl 별칭에 대한 완성 기능을 활성화하도록 구성하는 방법을 설명하겠습니다.

완전한 별칭 설치

우선, 완전한 별명은 다음에 달려 있습니다. bash 완성. 따라서 완전한 별칭을 설치하기 전에 bash-completion이 설치되어 있는지 확인해야 합니다. Linux 및 MacOS에 대한 설치 지침은 이전에 제공되었습니다.

MacOS 사용자를 위한 중요 참고 사항: kubectl 자동 완성 스크립트와 마찬가지로 완전한 별칭은 MacOS의 기본값인 Bash 3.2에서 작동하지 않습니다. 특히 완전한 별칭은 bash-completion v2(brew install bash-completion@2), 최소한 Bash 4.1이 필요합니다. 이는 MacOS에서 완전한 별칭을 사용하려면 최신 버전의 Bash를 설치해야 함을 의미합니다.

스크립트를 다운로드해야 합니다. bash_completion.sh 으로 GitHub 저장소 파일에 포함시키세요 ~/.bashrc:

source ~/bash_completion.sh

셸을 재부팅하면 완전한 별칭이 완전히 설치됩니다.

kubectl 별칭에 대한 자동 완성 활성화

기술적으로 완전한 별칭은 래퍼 기능을 제공합니다. _complete_alias. 이 함수는 별칭을 확인하고 별칭 명령에 대한 완료 힌트를 반환합니다.

함수를 특정 별칭과 연결하려면 내장된 Bash 메커니즘을 사용해야 합니다. 완전한, 설치하기 위해서 _complete_alias 별칭 완성 함수로.

예를 들어 kubectl 명령을 나타내는 별칭 k를 살펴보겠습니다. 설치하기 위해서 _complete_alias 이 별칭에 대한 보완 기능으로 다음 명령을 실행해야 합니다.

$ complete -F _complete_alias k

그 결과 별칭 k를 자동 완성할 때마다 함수가 호출됩니다. _complete_alias, 별칭을 확인하고 명령에 대한 완료 힌트를 반환합니다. kubectl.

두 번째 예로 별칭을 살펴보겠습니다. kg, 이는 다음을 나타냅니다. kubectl get:

$ complete -F _complete_alias kg

이전 예와 마찬가지로 kg을 자동 완성하면 에서 얻을 수 있는 것과 동일한 완료 힌트를 얻게 됩니다. kubectl get.

시스템의 모든 별칭에 대해 완전한 별칭을 사용할 수 있습니다.

따라서 모든 kubectl 별칭에 대해 자동 완성을 활성화하려면 각 별칭에 대해 위 명령을 실행해야 합니다. kubectl-aliases를 다음으로 설정한 경우 다음 스니펫은 이를 정확하게 수행합니다. ~/.kubectl-aliases:

for _a in $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases); 
do
  complete -F _complete_alias "$_a"
done

이 코드 조각은 ~/.bashrc, 명령 셸을 다시 시작하면 모든 800개의 kubectl 별칭에 대해 자동 완성을 사용할 수 있게 됩니다.

6. 플러그인으로 kubectl 확장하기

~부터 시작 버전 1.12, kubectl은 지원합니다 플러그인 메커니즘, 추가 명령을 사용하여 기능을 확장할 수 있습니다.

당신이 익숙한 경우 Git 플러그인 메커니즘, kubectl 플러그인은 동일한 원칙에 따라 구축됩니다.

이 장에서는 플러그인을 설치하는 방법, 플러그인을 찾을 수 있는 위치, 자신만의 플러그인을 만드는 방법에 대해 설명합니다.

플러그인 설치

Kubectl 플러그인은 다음과 같은 이름을 가진 간단한 실행 파일로 배포됩니다. kubectl-x. 접두사 kubectl- 필수이며, 그 뒤에 플러그인을 호출할 수 있는 새로운 kubectl 하위 명령이 옵니다.

예를 들어 hello 플러그인은 다음과 같은 파일로 배포됩니다. kubectl-hello.

플러그인을 설치하려면 파일을 복사해야 합니다. kubectl-x PATH의 임의의 디렉토리로 이동하여 실행 가능하게 만듭니다. 예를 들어 다음과 같습니다. chmod +x. 그 직후에 다음을 사용하여 플러그인을 호출할 수 있습니다. kubectl x.

다음 명령을 사용하여 현재 시스템에 설치된 모든 플러그인을 나열할 수 있습니다.

$ kubectl plugin list

이 명령은 동일한 이름을 가진 플러그인이 여러 개 있거나 실행할 수 없는 플러그인 파일이 있는 경우에도 경고를 표시합니다.

Krew를 사용하여 플러그인 찾기 및 설치

Kubectl 플러그인은 소프트웨어 패키지처럼 공유하거나 재사용할 수 있습니다. 하지만 다른 사람들이 공유한 플러그인은 어디서 찾을 수 있나요?

프로젝트 크루 kubectl 플러그인을 공유, 검색, 설치 및 관리하기 위한 통합 솔루션을 제공하는 것을 목표로 합니다. 프로젝트는 스스로를 "kubectl 플러그인용 패키지 관리자"라고 부릅니다(Krew는 다음과 유사합니다). 꾸미다).

Krew는 선택하고 설치할 수 있는 kubectl 플러그인 목록입니다. 동시에 Krew는 kubectl용 플러그인이기도 합니다.

이는 Krew 설치가 기본적으로 다른 kubectl 플러그인 설치와 동일하게 작동한다는 것을 의미합니다. 자세한 지침은 다음에서 확인할 수 있습니다. GitHub 살펴보기.

가장 중요한 Krew 명령은 다음과 같습니다:

# Поиск в списке плагинов
$ kubectl krew search [<query>]
# Посмотреть информацию о плагине
$ kubectl krew info <plugin>
# Установить плагин
$ kubectl krew install <plugin>
# Обновить все плагины до последней версии
$ kubectl krew upgrade
# Посмотреть все плагины, установленные через Krew
$ kubectl krew list
# Деинсталлировать плагин
$ kubectl krew remove <plugin>

Krew를 사용하여 플러그인을 설치해도 위에서 설명한 표준 방법을 사용하여 플러그인을 설치하는 데 방해가 되지 않습니다.

명령어를 참고해주세요 kubectl krew list Krew를 사용하여 설치된 플러그인만 표시하는 반면, 명령은 kubectl plugin list 모든 플러그인, 즉 Krew를 사용하여 설치된 플러그인과 다른 방법으로 설치된 플러그인을 나열합니다.

다른 곳에서 플러그인 찾기

Krew는 현재 진행 중인 젊은 프로젝트입니다. 목록 약 30개의 플러그인만 있습니다. 필요한 것을 찾을 수 없다면 GitHub와 같은 다른 곳에서 플러그인을 찾을 수 있습니다.

GitHub 섹션을 살펴보는 것이 좋습니다. kubectl-플러그인. 여기서는 확인해 볼 가치가 있는 수십 개의 플러그인을 찾을 수 있습니다.

나만의 플러그인 작성

당신은 스스로 할 수 있습니다 플러그인 만들기 - 어렵지 않아요. 필요한 작업을 수행하는 실행 파일을 만들고 이름을 다음과 같이 지정해야 합니다. kubectl-x 그리고 위에서 설명한 대로 설치합니다.

파일은 bash 스크립트, Python 스크립트 또는 컴파일된 GO 애플리케이션일 수 있습니다. 이는 중요하지 않습니다. 유일한 조건은 운영 체제에서 직접 실행할 수 있다는 것입니다.

지금 바로 예제 플러그인을 만들어 보겠습니다. 이전 섹션에서는 kubectl 명령을 사용하여 각 Pod의 컨테이너를 나열했습니다. 이 명령을 호출할 수 있는 플러그인으로 바꾸는 것은 쉽습니다. kubectl img.

파일 만들기 kubectl-img 다음 내용 :

#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

이제 파일을 실행 가능하게 만드십시오. chmod +x kubectl-img PATH의 임의의 디렉토리로 이동하십시오. 그 직후에 플러그인을 사용할 수 있습니다 kubectl img.

언급한 대로 kubectl 플러그인은 모든 프로그래밍 또는 스크립팅 언어로 작성될 수 있습니다. 쉘 스크립트를 사용하는 경우 플러그인 내에서 kubectl을 쉽게 호출할 수 있다는 이점이 있습니다. 그러나 다음을 사용하여 실제 프로그래밍 언어로 더 복잡한 플러그인을 작성할 수 있습니다. Kubernetes 클라이언트 라이브러리. Go를 사용하는 경우 다음을 사용할 수도 있습니다. cli 런타임 라이브러리, 이는 kubectl 플러그인 작성을 위해 특별히 존재합니다.

플러그인을 공유하는 방법

귀하의 플러그인이 다른 사람들에게 유용할 수 있다고 생각한다면 GitHub에서 자유롭게 공유해 주세요. 주제에 꼭 추가하세요 kubectl-플러그인.

플러그인을 추가하도록 요청할 수도 있습니다. 크루 목록. 이를 수행하는 방법에 대한 지침은 GitHub 저장소.

명령 완성

플러그인은 현재 자동 완성을 지원하지 않습니다. 즉, 플러그인의 전체 이름과 인수의 전체 이름을 입력해야 합니다.

이 함수에 대한 GitHub kubectl 저장소에는 공개 요청. 따라서 이 기능은 향후 언젠가 구현될 가능성이 있습니다.

행운을 빌어 요 !!!

주제에 대해 더 읽을 내용:

1. Kubernetes의 세 가지 수준의 자동 확장 및 이를 효과적으로 사용하는 방법.
2. 구현을 위한 템플릿을 갖춘 불법 복제 정신의 Kubernetes.
3. Telegram의 Kubernetes 주변 채널.

출처 : habr.com