최소 실행 가능한 Kubernetes

기사의 번역은 과정 시작 전날에 준비되었습니다. "DevOps 사례 및 도구".

이 글을 읽고 계시다면 아마도 Kubernetes에 대해 들어보셨을 것입니다(아니면 어떻게 여기까지 오셨나요?). 하지만 Kubernetes란 정확히 무엇인가요? 이것 “산업용 컨테이너의 편성”? 또는 "클라우드 네이티브 운영 체제"? 이것은 무엇을 의미합니까?

솔직히 말해서 100% 확신할 수는 없습니다. 하지만 내부를 파헤쳐 여러 추상화 계층 아래 Kubernetes에서 실제로 무슨 일이 일어나고 있는지 보는 것은 흥미롭다고 생각합니다. 그럼 재미삼아 최소한의 "Kubernetes 클러스터"가 실제로 어떻게 보이는지 살펴보겠습니다. (이것은 것보다 훨씬 쉬울 것입니다. Kubernetes의 어려운 방법.)

Kubernetes, Linux 및 컨테이너에 대한 기본 지식이 있다고 가정합니다. 여기서 이야기하는 모든 내용은 연구/학습 목적으로만 사용되며 프로덕션에 적용되지 않습니다!

검토

Kubernetes에는 많은 구성 요소가 포함되어 있습니다. 에 따르면 위키 백과, 아키텍처는 다음과 같습니다.

여기에는 최소 XNUMX개의 구성 요소가 표시되어 있지만 대부분은 무시하겠습니다. Kubernetes라고 합리적으로 부를 수 있는 최소한의 요소는 세 가지 주요 구성 요소로 구성되어 있다고 말하고 싶습니다.

• Kubelet
• kube-apiserver(etcd에 따라 다름 - 해당 데이터베이스)
• 컨테이너 런타임(이 경우 Docker)

문서에서 각각에 대해 뭐라고 말하는지 살펴보겠습니다(루스., 영어.). 처음에는 Kubelet:

클러스터의 각 노드에서 실행되는 에이전트입니다. 컨테이너가 포드에서 실행되고 있는지 확인합니다.

충분히 간단하게 들립니다. 는 어때 컨테이너 런타임 (컨테이너 런타임)?

컨테이너 런타임은 컨테이너를 실행하도록 설계된 프로그램입니다.

매우 유익합니다. 하지만 Docker에 익숙하다면 Docker가 수행하는 작업에 대한 일반적인 아이디어가 있어야 합니다. (컨테이너 런타임과 kubelet 간의 책임 분리에 대한 세부 사항은 실제로 매우 미묘하므로 여기서는 다루지 않겠습니다.)

И API 서버?

API 서버는 Kubernetes API를 노출하는 Kubernetes 제어판 구성 요소입니다. API 서버는 Kubernetes 제어판의 클라이언트 측입니다.

Kubernetes를 사용해 본 적이 있는 사람이라면 누구나 직접 또는 kubectl을 통해 API와 상호작용해야 했습니다. 이것이 Kubernetes Kubernetes를 만드는 핵심입니다. 우리 모두가 알고 사랑하는(?) 산더미 같은 YAML을 작동하는 인프라로 바꾸는 두뇌입니다. API가 최소한의 구성에 있어야 한다는 것은 분명한 것 같습니다.

전제 조건

• 루트 액세스 권한이 있는 Linux 가상 또는 물리적 머신(가상 머신에서 Ubuntu 18.04를 사용하고 있습니다).
• 그리고 그게 다야!

지루한 설치

우리가 사용할 머신에 Docker를 설치해야 합니다. (Docker와 컨테이너의 작동 방식에 대해서는 자세히 설명하지 않겠습니다. 관심이 있으시면 멋진 기사). 그냥 설치하자 apt:

$ sudo apt install docker.io
$ sudo systemctl start docker

그런 다음 Kubernetes 바이너리를 가져와야 합니다. 실제로 "클러스터"를 처음 시작하는 경우에만 필요합니다. kubelet, 다른 서버 구성요소를 실행하기 위해 사용할 수 있으므로 kubelet. 클러스터가 실행된 후 클러스터와 상호 작용하기 위해 다음도 사용합니다. kubectl.

$ curl -L https://dl.k8s.io/v1.18.5/kubernetes-server-linux-amd64.tar.gz > server.tar.gz
$ tar xzvf server.tar.gz
$ cp kubernetes/server/bin/kubelet .
$ cp kubernetes/server/bin/kubectl .
$ ./kubelet --version
Kubernetes v1.18.5

그냥 달리면 어떻게 될까요? kubelet?

$ ./kubelet
F0609 04:03:29.105194    4583 server.go:254] mkdir /var/lib/kubelet: permission denied

kubelet 루트로 실행해야 합니다. 그는 전체 노드를 관리해야 하므로 매우 논리적입니다. 해당 매개변수를 살펴보겠습니다.

$ ./kubelet -h
<слишком много строк, чтобы разместить здесь>
$ ./kubelet -h | wc -l
284

와, 옵션이 너무 많아요! 운 좋게도 우리는 그것들 중 몇 개만 필요합니다. 우리가 관심을 갖고 있는 매개변수 중 하나는 다음과 같습니다.

--pod-manifest-path string

정적 포드용 파일이 포함된 디렉터리 경로 또는 정적 포드를 설명하는 파일 경로입니다. 점으로 시작하는 파일은 무시됩니다. (지원 중단됨: 이 옵션은 --config 옵션을 통해 Kubelet에 전달된 구성 파일에 설정되어야 합니다. 자세한 내용은 다음을 참조하세요. kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file .)

이 옵션을 사용하면 다음을 실행할 수 있습니다. 정적 포드 — Kubernetes API를 통해 관리되지 않는 포드. 정적 포드는 거의 사용되지 않지만 클러스터를 빠르게 늘리는 데 매우 편리하며 이것이 바로 우리에게 필요한 것입니다. 우리는 이 큰 경고를 무시하고(다시 말하지만, 프로덕션 환경에서는 실행하지 마십시오!) 포드를 실행할 수 있는지 살펴보겠습니다.

먼저 정적 포드용 디렉터리를 만들고 실행합니다. kubelet:

$ mkdir pods
$ sudo ./kubelet --pod-manifest-path=pods

그런 다음 다른 터미널/tmux 창 등에서 포드 매니페스트를 생성합니다.

$ cat <<EOF > pods/hello.yaml
apiVersion: v1
kind: Pod
metadata:
  name: hello
spec:
  containers:
  - image: busybox
    name: hello
    command: ["echo", "hello world!"]
EOF

kubelet 몇 가지 경고를 쓰기 시작했는데 아무 일도 일어나지 않는 것 같습니다. 하지만 그것은 사실이 아닙니다! 도커를 살펴보겠습니다:

$ sudo docker ps -a
CONTAINER ID        IMAGE                  COMMAND                 CREATED             STATUS                      PORTS               NAMES
8c8a35e26663        busybox                "echo 'hello world!'"   36 seconds ago      Exited (0) 36 seconds ago                       k8s_hello_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_4
68f670c3c85f        k8s.gcr.io/pause:3.2   "/pause"                2 minutes ago       Up 2 minutes                                    k8s_POD_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_0
$ sudo docker logs k8s_hello_hello-mink8s_default_ab61ef0307c6e0dee2ab05dc1ff94812_4
hello world!

kubelet 나는 포드 매니페스트를 읽고 우리 사양에 따라 두 개의 컨테이너를 시작하라는 명령을 Docker에 제공했습니다. ("일시 중지" 컨테이너에 대해 궁금하다면 이는 Kubernetes 해킹입니다. 이 블로그.) Kubelet이 컨테이너를 출시할 것입니다. busybox 지정된 명령을 사용하면 정적 포드가 삭제될 때까지 무기한 다시 시작됩니다.

자신을 축하합니다. 우리는 터미널에 텍스트를 출력하는 가장 혼란스러운 방법 중 하나를 생각해냈습니다!

etcd 실행

우리의 궁극적인 목표는 Kubernetes API를 실행하는 것입니다. 하지만 그러기 위해서는 먼저 다음을 실행해야 합니다. 등. Pods 디렉터리에 해당 설정을 배치하여 최소 etcd 클러스터를 시작하겠습니다(예: pods/etcd.yaml):

apiVersion: v1
kind: Pod
metadata:
  name: etcd
  namespace: kube-system
spec:
  containers:
  - name: etcd
    command:
    - etcd
    - --data-dir=/var/lib/etcd
    image: k8s.gcr.io/etcd:3.4.3-0
    volumeMounts:
    - mountPath: /var/lib/etcd
      name: etcd-data
  hostNetwork: true
  volumes:
  - hostPath:
      path: /var/lib/etcd
      type: DirectoryOrCreate
    name: etcd-data

Kubernetes를 사용해 본 적이 있다면 이러한 YAML 파일이 익숙할 것입니다. 여기서 주목할 만한 점은 두 가지뿐입니다.

호스트 폴더를 마운트했습니다 /var/lib/etcd 다시 시작한 후 etcd 데이터가 보존되도록 포드에서(이렇게 하지 않으면 포드를 다시 시작할 때마다 클러스터 상태가 지워지므로 최소한의 Kubernetes 설치에도 적합하지 않습니다).

우리는 설치했습니다 hostNetwork: true. 당연히 이 설정은 Pod의 내부 네트워크 대신 호스트 네트워크를 사용하도록 etcd를 구성합니다(이렇게 하면 API 서버가 etcd 클러스터를 더 쉽게 찾을 수 있습니다).

간단한 검사를 통해 etcd가 실제로 localhost에서 실행 중이고 데이터를 디스크에 저장하고 있음을 알 수 있습니다.

$ curl localhost:2379/version
{"etcdserver":"3.4.3","etcdcluster":"3.4.0"}
$ sudo tree /var/lib/etcd/
/var/lib/etcd/
└── member
    ├── snap
    │   └── db
    └── wal
        ├── 0.tmp
        └── 0000000000000000-0000000000000000.wal

API 서버 시작

Kubernetes API 서버를 실행하는 것이 훨씬 더 쉽습니다. 전달해야 하는 유일한 매개변수는 다음과 같습니다. --etcd-servers, 예상한 대로 수행됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - name: kube-apiserver
    command:
    - kube-apiserver
    - --etcd-servers=http://127.0.0.1:2379
    image: k8s.gcr.io/kube-apiserver:v1.18.5
  hostNetwork: true

이 YAML 파일을 디렉터리에 배치합니다. pods, API 서버가 시작됩니다. 확인 중 curl Kubernetes API가 완전히 개방된 액세스로 포트 8080에서 수신 대기하고 있음을 보여줍니다. 인증이 필요하지 않습니다.

$ curl localhost:8080/healthz
ok
$ curl localhost:8080/api/v1/pods
{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "selfLink": "/api/v1/pods",
    "resourceVersion": "59"
  },
  "items": []
}

(다시 한번 말하지만, 이것을 프로덕션 환경에서 실행하지 마세요! 기본 설정이 너무 안전하지 않아서 조금 놀랐습니다. 하지만 이것이 개발과 테스트를 더 쉽게 하기 위한 것이라고 생각합니다.)

그리고 놀랍게도 kubectl은 추가 설정 없이 즉시 작동합니다!

$ ./kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:47:41Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:39:24Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
$ ./kubectl get pod
No resources found in default namespace.

문제

하지만 조금 더 깊이 파고들어 보면 뭔가 잘못되고 있는 것 같습니다.

$ ./kubectl get pod -n kube-system
No resources found in kube-system namespace.

우리가 만든 정적 포드가 사라졌습니다! 실제로 kubelet 노드는 전혀 검색되지 않습니다.

$ ./kubectl get nodes
No resources found in default namespace.

무슨 일이야? 몇 단락 전을 기억하신다면, 우리는 매우 간단한 명령줄 매개변수 세트로 kubelet을 시작했기 때문에 kubelet은 API 서버에 접속하고 상태를 알리는 방법을 알지 못합니다. 문서를 연구한 후 해당 플래그를 찾습니다.

--kubeconfig string

파일의 경로 kubeconfig, API 서버에 연결하는 방법을 지정합니다. 유효성 --kubeconfig API 서버 모드를 활성화합니다. 아니요 --kubeconfig 오프라인 모드를 활성화합니다.

그동안 우리는 자신도 모르게 kubelet을 "오프라인 모드"로 실행하고 있었습니다. (현학적으로 말하면 독립형 kubelet을 "최소 실행 가능한 Kubernetes"로 생각할 수 있지만 이는 매우 지루할 것입니다). "실제" 구성이 작동하도록 하려면 kubeconfig 파일을 kubelet에 전달하여 API 서버와 통신하는 방법을 알아야 합니다. 운 좋게도 매우 간단합니다(인증이나 인증서 문제가 없기 때문에).

apiVersion: v1
kind: Config
clusters:
- cluster:
    server: http://127.0.0.1:8080
  name: mink8s
contexts:
- context:
    cluster: mink8s
  name: mink8s
current-context: mink8s

이것을 다른 이름으로 저장 kubeconfig.yaml, 프로세스 종료 kubelet 필요한 매개변수로 다시 시작합니다.

$ sudo ./kubelet --pod-manifest-path=pods --kubeconfig=kubeconfig.yaml

(그런데, kubelet이 실행되지 않을 때 컬을 통해 API에 접근하려고 하면 여전히 실행 중이라는 것을 알게 될 것입니다! Kubelet은 Docker와 같은 Pod의 "상위"가 아니라 "컨트롤"에 가깝습니다. daemon.” kubelet이 관리하는 컨테이너는 kubelet이 중지할 때까지 계속 실행됩니다.)

몇 분 안에 kubectl 예상한 대로 포드와 노드가 표시되어야 합니다.

$ ./kubectl get pods -A
NAMESPACE     NAME                    READY   STATUS             RESTARTS   AGE
default       hello-mink8s            0/1     CrashLoopBackOff   261        21h
kube-system   etcd-mink8s             1/1     Running            0          21h
kube-system   kube-apiserver-mink8s   1/1     Running            0          21h
$ ./kubectl get nodes -owide
NAME     STATUS   ROLES    AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
mink8s   Ready    <none>   21h   v1.18.5   10.70.10.228   <none>        Ubuntu 18.04.4 LTS   4.15.0-109-generic   docker://19.3.6

이번에는 정말로 축하해 봅시다(이미 축하했다는 것을 알고 있습니다). 완전한 기능을 갖춘 API로 실행되는 최소한의 Kubernetes "클러스터"가 있습니다!

우리는 아래에서 시작합니다

이제 API가 무엇을 할 수 있는지 살펴보겠습니다. nginx 포드부터 시작해 보겠습니다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx

여기서는 다소 흥미로운 오류가 발생합니다.

$ ./kubectl apply -f nginx.yaml
Error from server (Forbidden): error when creating "nginx.yaml": pods "nginx" is
forbidden: error looking up service account default/default: serviceaccount
"default" not found
$ ./kubectl get serviceaccounts
No resources found in default namespace.

여기서 우리는 Kubernetes 환경이 얼마나 비참할 정도로 불완전한지 알 수 있습니다. 서비스에 대한 계정이 없습니다. 서비스 계정을 수동으로 만들어 다시 시도하고 무슨 일이 일어나는지 살펴보겠습니다.

$ cat <<EOS | ./kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
EOS
serviceaccount/default created
$ ./kubectl apply -f nginx.yaml
Error from server (ServerTimeout): error when creating "nginx.yaml": No API
token found for service account "default", retry after the token is
automatically created and added to the service account

서비스 계정을 수동으로 생성하더라도 인증 토큰이 생성되지 않습니다. 최소한의 "클러스터"를 계속 실험해 보면 일반적으로 자동으로 발생하는 대부분의 유용한 기능이 누락된다는 사실을 알게 될 것입니다. Kubernetes API 서버는 아직 실행되지 않은 다양한 컨트롤러 및 백그라운드 작업에서 대부분의 무거운 작업 및 자동 구성이 발생하므로 매우 미니멀합니다.

옵션을 설정하여 이 문제를 해결할 수 있습니다. automountServiceAccountToken 서비스 계정의 경우(어차피 사용할 필요가 없으므로):

$ cat <<EOS | ./kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
automountServiceAccountToken: false
EOS
serviceaccount/default configured
$ ./kubectl apply -f nginx.yaml
pod/nginx created
$ ./kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   0/1     Pending   0          13m

드디어 팟이 등장했어요! 하지만 실제로는 우리가 없기 때문에 시작되지 않습니다 입안자 (스케줄러)는 Kubernetes의 또 다른 중요한 구성 요소입니다. 다시 말하지만, Kubernetes API는 놀랍게도 "멍청하다"는 것을 알 수 있습니다. API에서 Pod를 생성하면 이를 등록하지만 어떤 노드에서 실행할지 파악하려고 시도하지 않습니다.

실제로 Pod를 실행하는 데 스케줄러가 필요하지 않습니다. 매개변수의 매니페스트에 노드를 수동으로 추가할 수 있습니다. nodeName:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
  nodeName: mink8s

(바꾸다 mink8s 노드 이름에.) 삭제하고 적용한 후 nginx가 시작되어 내부 IP 주소를 수신하는 것을 볼 수 있습니다.

$ ./kubectl delete pod nginx
pod "nginx" deleted
$ ./kubectl apply -f nginx.yaml
pod/nginx created
$ ./kubectl get pods -owide
NAME    READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          30s   172.17.0.2   mink8s   <none>           <none>
$ curl -s 172.17.0.2 | head -4
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

포드 간의 네트워크가 올바르게 작동하는지 확인하기 위해 다른 포드에서 컬을 실행할 수 있습니다.

$ cat <<EOS | ./kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  containers:
  - image: curlimages/curl
    name: curl
    command: ["curl", "172.17.0.2"]
  nodeName: mink8s
EOS
pod/curl created
$ ./kubectl logs curl | head -6
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

이 환경을 파헤쳐 무엇이 효과가 있고 무엇이 효과가 없는지 알아보는 것은 매우 흥미롭습니다. ConfigMap과 Secret은 예상대로 작동하지만 Service와 배포는 작동하지 않는 것으로 나타났습니다.

성공!

포스팅이 너무 길어져서 승리를 선언하고 이것이 "Kubernetes"라고 부를 수 있는 실행 가능한 구성이라고 말하고 싶습니다. 요약하자면: 45개의 바이너리, XNUMX개의 명령줄 매개변수 및 "단지" XNUMX줄의 YAML(아닙니다) Kubernetes 표준에 따르면 그 정도) 우리는 몇 가지 작업을 수행하고 있습니다.

• Pod는 일반 Kubernetes API를 사용하여 관리됩니다(몇 가지 해킹 포함).
• 공용 컨테이너 이미지를 업로드하고 관리할 수 있습니다.
• 포드는 활성 상태로 유지되며 자동으로 다시 시작됩니다.
• 동일한 노드 내의 포드 간 네트워킹은 매우 잘 작동합니다.
• ConfigMap, Secret 및 간단한 스토리지 마운팅이 예상대로 작동합니다.

그러나 Kubernetes를 진정으로 유용하게 만드는 다음과 같은 많은 요소가 아직 누락되었습니다.

• 포드 스케줄러
• 인증/승인
• 다중 노드
• 서비스 네트워크
• 클러스터링된 내부 DNS
• 서비스 계정, 배포, 클라우드 제공업체와의 통합 및 Kubernetes가 제공하는 대부분의 기타 기능을 위한 컨트롤러

그렇다면 우리는 실제로 무엇을 얻었습니까? 자체적으로 실행되는 Kubernetes API는 실제로는 컨테이너 자동화. API를 사용하는 다양한 컨트롤러와 운영자를 위한 작업이지만, 자동화를 위한 일관된 환경을 제공합니다.

무료 웹 세미나에서 해당 과정에 대해 자세히 알아보세요.

더 읽어보기 :

• 시스템 관리자, 개발자 및 테스터가 DevOps 사례를 배워야 하는 이유는 무엇입니까?
• 타노스 - 확장 가능한 프로메테우스
• GitLab QA 팀이 GitLab 성능 도구를 사용하는 방법
• Loki - Prometheus 접근 방식을 사용하여 로그 수집
• DevOps 생활의 하루

출처 : habr.com