最小実行可能Kubernetes

記事の翻訳は、コース「DevOpsの実践とツール」の開始に先立って作成されました。

---

これを読んでいるなら、おそらくKubernetesについて何か聞いたことがあるでしょう（そうでない場合は、どうやってここにたどり着いたのですか？）しかし、Kubernetesとは正確には何ですか？これは「工業用グレードのコンテナオーケストレーション」ですか？または「クラウドネイティブオペレーティングシステム」？とにかくこれはどういう意味ですか？



正直なところ、100％確信はありません。しかし、内部を掘り下げて、Kubernetesの多くの抽象化層の下で実際に何が起こっているのかを見るのは興味深いと思います。楽しみのために、最小限の「Kubernetesクラスター」が実際にどのように見えるかを見てみましょう。 （これは、Kubernetes The Hard Wayよりもはるかに簡単です。）



Kubernetes、Linux、およびコンテナの基本的な知識があることを前提としています。ここで説明することはすべて、調査/研究のみを目的としています。これを本番環境で実行しないでください。

概要概要

Kubernetesには多くのコンポーネントが含まれています。ウィキペディアによると、アーキテクチャは次のようになります。







ここには少なくとも8つのコンポーネントが示されていますが、それらのほとんどは無視します。Kubernetesと合理的に呼ぶことができる最小のものには、3つの主要なコンポーネントがあることを述べたいと思います。

• kubelet
• kube-apiserver（etcdに依存-そのデータベース）
• コンテナランタイム（この場合はDocker）

それらのそれぞれについてドキュメントが何を言っているか見てみましょう（ロシア語、英語）。最初にkubelet：



クラスター内のすべてのノードで実行されているエージェント。彼は、コンテナがポッド内で実行されていることを確認します。



簡単そうに聞こえます。何についての実行時のコンテナ（コンテナ・ランタイム）？



コンテナランタイムは、コンテナを実行するために設計されたプログラムです。



非常に有益です。ただし、Dockerに精通している場合は、Dockerの機能について基本的な知識が必要です。 （コンテナランタイムとkubeletの間の懸念の分離の詳細は実際には非常に微妙なので、ここでは説明しません。）



そしてサーバーAPI？



APIサーバー-KubernetesAPIを表す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

うわー、たくさんのオプションがあります！幸いなことに、必要なのはそのうちの2つだけです。これが私たちが興味を持っているパラメータの1つです：

--pod-manifest-path string

静的ポッドのファイルを含むディレクトリへのパス、または静的ポッドを説明するファイルへのパス。ピリオドで始まるファイルは無視されます。 （非推奨：このパラメーターは、-configオプションを介してKubeletに渡される構成ファイルで設定する必要があります。詳細については、kubernetes.io / docs / tasks / administer-cluster / kubelet-config-fileを参照してください。）



このパラメーターを使用すると、静的に実行できます。ポッド-KubernetesAPIを介して管理されないポッド。静的ポッドはめったに使用されませんが、クラスターをすばやく上げるのに非常に便利であり、まさにこれが必要です。この大きな警告は無視します（繰り返しますが、これを本番環境で実行しないでください！）そして、実行できるかどうかを確認します。



まず、静的ポッド用のディレクトリを作成して実行します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いくつかの警告を書き始めましたが、何も起こっていないようです。しかし、そうではありません！Dockerを見てみましょう。

$ 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、指定されたコマンドでコンテナを起動し、静的ポッドが削除されるまで無期限に再起動します。



おめでとうございます。ターミナルにテキストを出力するための最も複雑な方法の1つを思いついたところです。

etcdを実行します

私たちの最終的な目標はKubernetesAPIを実行することですが、そのためには最初にetcdを実行する必要があります。 podsディレクトリ（たとえばpods/etcd.yaml）に設定を配置して、最小限のetcdクラスターを開始しましょう。

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ファイルに精通している必要があります。ここで注意すべき点は2つだけです。再起動後にetcdデータが保存



されるように、ホストフォルダー/var/lib/etcdをポッドにマウントしました（これを行わないと、ポッドを再起動するたびにクラスターの状態が消去されます。これは、最小限のKubernetesインストールでも問題になります）。



インストールしましたhostNetwork: true。このオプションは、当然のことながら、ポッドの内部ネットワークの代わりにホストネットワークを使用するように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 APIServerの起動はさらに簡単です。渡す必要がある唯一のパラメーターは--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サーバーが起動します。ヘルプによる検証は、curlKubernetes 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サーバーに接続してその状態を通知する方法を知りません。ドキュメントを調べた後、対応するフラグが見つかりました。APIサーバーへの接続方法を示す



--kubeconfig string



ファイルへのパスkubeconfig。存在--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がダウンしているときにcurlを使用してAPIにアクセスしようとすると、それでも機能することがわかります。Kubeletは、Dockerのようにポッドの「親」ではなく、「制御デーモン」のようなものです。 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のもう1つの重要なコンポーネント）がないため、起動しません。繰り返しになりますが、Kubernetes APIは驚くほどばかげていることがわかります。APIでポッドを作成すると、ポッドは登録されますが、実行するノードを特定しようとはしません。



ポッドを実行するのに実際にはスケジューラは必要ありません。パラメータでマニフェストにノードを手動で追加できます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>

ポッド間のネットワークが正しく機能していることを確認するために、別のポッドからcurlを実行できます。

$ 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とDeploymentは機能しません。

成功！

この投稿は大きくなっているので、勝利を発表し、これが「Kubernetes」を呼び出すための実行可能な構成であることを宣言します。要約すると、4つのバイナリ、5つのコマンドラインパラメータ、および「ちょうど」45行のYAML（標準では多くありません） Kubernetes）そして私たちはたくさんのことが働いています：

• ポッドは、通常のKubernetes APIを使用して管理されます（いくつかのハックがあります）
• パブリックコンテナイメージをアップロードおよび管理できます
• ポッドは存続し、自動的に再起動します
• 単一ノード内のポッド間のネットワークは非常にうまく機能します
• ConfigMap、リポジトリの秘密で最も簡単なマウントは期待どおりに機能します

しかし、Kubernetesを本当に便利にするもののほとんどは、まだ不足しています。たとえば、次のとおりです。

• ポッドプランナー
• 認証/承認
• 複数のノード
• サービスネットワーク
• クラスター化された内部DNS
• サービスアカウント、展開、クラウドプロバイダーの統合、およびKubernetesがもたらすその他のほとんどの機能のコントローラー

では、実際に何を得たのでしょうか。Kubernetes APIは、それ自体で動作し、実際には単なるコンテナ自動化プラットフォームです。APIを使用するさまざまなコントローラーやオペレーターに対しては機能しますが、自動化のための一貫したフレームワークを提供します。



無料のウェビナーでコースの詳細をご覧ください。

---

続きを読む：

• sysadmin、開発者、テスターがDevOpsの実践を学ぶ必要があるのはなぜですか？
• Thanos — Prometheus
• QA- GitLab GitLab Performance Tool
• Loki — , Prometheus
• DevOps