「Kubernetes the hard way」を図で理解したい -後編-

はじめに

前編の続き、後編です。

「Kubernetes the hard way」を図で理解したい -前編-

Nishipy自分の中でやるやる詐欺をしていた「Kubernetes the hard way」をやっていきます。前編では、全14章のうち1~6章まで。はじめにKubernetes The Hard Way とはGCP上...(続く)

Kubernetes the hard wayといやつをやってみたときのメモを残します。また各章に対して、適宜図などをつけてみます。

GitHub - kelseyhightower/kubernetes-the-hard-way: Bootstrap Kubernetes the hard way. No scripts.

Bootstrap Kubernetes the hard way. No scripts. Contribute to kelseyhightower/kubernetes-the-hard-way development by creating an account on GitHub.

今回の範囲

前回は6章までやったので、今回は7章から12章までをまとめていきたいと思います。Smoke TestとClean Upの章は省略します。

7.Bootstrapping the etcd Cluster
8.Bootstrapping the Kubernetes Control Plane
9.Bootstrapping the Kubernetes Worker Nodes
10.Configuring kubectl for Remote Access
11.Provisioning Pod Network Routes
12.Deploying the DNS Cluster Add-on

GCP上のVM構成

前回作成したVM構成は、こんな感じ。

これから作っていくKubernetesクラスタの構成

Kubernetesクラスタを構成する主なコンポーネントは以下です。図はWikipediaから引用しました。

7章からやっていく

7. Bootstrapping the etcd Cluster

Bootstrapping the etcd Cluster

Kubernetesでは、クラスタの状態などを表すデータを、マスターノードのコンポーネントであるetcdに保持します。読み方は、「イーティーシーディー」とか「エトセディー」とかがありますが、どれが正しいかは知りません。

etcdというのは、Go言語で書かれた分散Key-Value Storeであり、現在CNCFがホストするプロジェクトです。

etcd

A distributed, reliable key-value store for the most critical data of a distributed system Learn more Quickstart What is etcd? etcd is a strongly consistent, d...(続く)

GitHub - etcd-io/etcd: Distributed reliable key-value store for the most critical data of a distributed system

Distributed reliable key-value store for the most critical data of a distributed system - etcd-io/etcd

Kubernetesの公式ドキュメントによると、このetcdは3台以上の冗長構成を組むことが推奨されています。この「3台以上」という数字は、「Raft Consensus Algorithm」という分散合意アルゴリズムに依るものらしいです。2台構成でもし1台死ぬと、クラウス内のリーダーが選出できなくなるためだそうで、詳細は省きますが、以下の記事がとてもわかりやすいです。

Raft - Kubernetes(etcd)のHA構成はなぜ3台以上？ | TECHSCORE BLOG

Kubernetes コントロールプレーンの HA(High Available) 構成は二通りありますが、公式ドキュメント内に次のような記述があり、いずれの方式でも 3 台以上のマシンでクラスターを構成することが求められています。

さて7章では、マスターノード用のVM3台(controller-1, controller-2, controller-3)に対して、etcdのバイナリを入れて、3台でクラスタを組むための設定を入れていきます。VMのOSはLinuxなので、etcdもsysytemdで管理されることになります。

以下のコマンドを実行し、クラスタのメンバーの一覧が表示されれば成功です。

sudo systemctl daemon-reload

sudo systemctl enable etcd

sudo systemctl start etcd

sudo ETCDCTL_API=3 etcdctl member list \

--endpoints=https://127.0.0.1:2379 \

--cacert=/etc/etcd/ca.pem \

--cert=/etc/etcd/kubernetes.pem \

--key=/etc/etcd/kubernetes-key.pem

8. Bootstrapping the Kubernetes Control Plane

Bootstrapping the Kubernetes Control Plane

8章では、マスターノードを構築していきます。

コンポーネントの導入

以下のコンポーネントも入れていきます。etcdの時と同様に、バイナリをダウンロードして導入します。これらのサービスも今回はsysytemdで管理されます。

kube-api-server: Kubernetes APIを外部に提供する、マスター上のコンポーネント。Kubernetesコントロールプレーンのフロントエンド
kube-controller-manager: マスター上で動くcontrollersを動かすコンポーネント。論理的には、各controllerは、それぞれ別のプロセスだが、複雑になるのを避けるため、一つの実行ファイルにまとめてコンパイルされ、単一のプロセスとして動く
kube-scheduler: まだノードに紐付けられていない新規に作成されたPodを見張り、稼働させるべきノードを選択する

Kubernetes道場 24日目 - Kubernetesの各コンポーネントについて - Toku's Blog

この記事は Kubernetes道場 Advent Calendar 2018 24日目の記事です。今回はKubernetesの各コンポーネントについて見ていこう。 Kubernetesの各コンポーネントについて Kubernetesには以下のようなコンポーネントがある。 kubectl etcd kube-apis...(続く)

RBACの設定

Kubernetes API Serverから、Workerノードのkubeletにアクセスするために、RBACの設定を行います。Kubernetes API→kubeletの通信は、ログ/メトリクスの取得やPod内でコマンド実行のために行われます。

ちなみにRBACとは、Role Based Access Controlの略で、Kubernetesデフォルトの認可モジュールです。

Using RBAC Authorization

Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organizati...(続く)

主にRole/ClusterRoleとRoleBinding/ClusterRoleBindingというリソースがあります。Clusterが付くとクラスタ単位であり、Clusterが付かないとNamespace単位です。Roleをまず作成して権限を設定します。次にRoleBindingを作成して Roleとユーザまたは RoleとServiceAccount を紐付けます。(唐突な手書きメモ)

さて、今回の設定の手順は、以下の通りらしい。
* ClusterRole作成
* system:kube-apiserver-to-kubelet
* kubeletにアクセスして、あれこれできるいい感じの権限を与える。以下抜粋。

rules:

- apiGroups:

- ""

resources:

- nodes/proxy

- nodes/stats

- nodes/log

- nodes/spec

- nodes/metrics

verbs:

- "*"

ClusterRoleBinding作成
- 上で作成したRoleと、kubernetesというユーザを紐づける

apiVersion: rbac.authorization.k8s.io/v1beta1

kind: ClusterRoleBinding

metadata:

namespace: ""

roleRef:

apiGroup: rbac.authorization.k8s.io

kind: ClusterRole

subjects:

- apiGroup: rbac.authorization.k8s.io

kind: User

余談ですが、認証と認可の違いは、転職活動での技術面接でよく聞かれたので、知らない方は以下の記事も参照ください。すごくわかりやすい。

よくわかる認証と認可 | DevelopersIO

Kubernetes API Serverの前段にLBの導入

Google Network Load Balancerを導入して、Kubernetes API Serverへのアクセスを分散させる。

9. Bootstrapping the Kubernetes Worker Nodes

Bootstrapping the Kubernetes Worker Nodes

Swapの無効化

このあと導入するkubeletは、swapが有効だと起動に失敗するのがデフォルトらしいので、下記コマンドで無効化する。

1	sudo swapoff -a

ワーカーノードのコンポーネント導入

マスターノードの次は、Workerノードを構築していきます。各Workerノードに対して、以下のコンポーネントを設定していきます。

コンテナランタイム: High Level と Low Level

Kubernetesでデプロイするコンテナを動かすため、コンテナランタイムを導入します。コンテナランタイムについては、以下の記事(シリーズ)がわかりやすいです。

Container Runtimes Part 1: An Introduction to Container Runtimes

One of the terms you hear a lot when dealing with containers is “container runtime”. “Container runtime” can have different meanings to different people so it’s...(続く)

コンテナランタイムは、ハイレベルコンテナランタイムとローレベルコンテナに分けることができます。

High Levelコンテナランタイム
- kubeletと連携する。コンテナイメージ展開やローレベルコンテナランタイムへの受け渡しを担当。
Low Levelコンテナランタイム
- 実際のコンテナを管理する

containerdは、High Levelコンテナランタイムの1つ。runcは、Low Levelコンテナランタイムの1つ。どちらも、もともとDockerが開発していたが、CNCF寄贈された際に改名して、今の名前になったらしい。

みなさんもよくご存知のDockerも、分解すると以下のようなアーキテクチャになるそうです。dockerコマンドしか打たないので、意識することはないですが、知っておいて損はなさそうですね。

引用元: https://www.docker.com/blog/docker-engine-1-11-runc/

余談: CRI と OCI

コンテナランタイムのレイヤとして、High LevelとLow Levelがあると書きました。Kubernetesでは、[kubelet]-[High Levelコンテナランタイム]-[Low Levelコンテナランタイム]が連携して、コンテナを動かすわけですが、それぞれのインターフェイスの規格は、CRI（Container Runtime Interface）と OCI（Open Container Initiative）によって、標準化されているようです。

こちらの記事も参照ください。

Container Runtimes Part 4: Kubernetes Container Runtimes & CRI

This is the fourth and last part in a four part series on container runtimes. It’s been a while since part 1, but in that post I gave an overview of container r...(続く)

コンテナランタイムの動向を整理してみた件 - Qiita

はじめに先日以下のQiita記事を書いたのですが、公開した後にコンテナランタイムについて全然書いていないことに気付いたので、今度はコンテナランタイムの動向について整理してみたいと思います。Doc…

CNI Networking

CNI (Container Network Interface)は、CNCFのプロジェクトの1つであり、Linuxコンテナ内のネットワークインターフェイスの設定を行うプラグインを書く上での規格やライブラリから成ります。(直訳)

GitHub - containernetworking/cni: Container Network Interface - networking for Linux containers

Container Network Interface - networking for Linux containers - containernetworking/cni

要はコンテナが作成されたときにネットワークリソースをいい感じに構成して接続性を確保し、コンテナが削除されたときにネットワークリソースを開放します。この説明から分かる通り、私も正直よくわかっていないので以下のスライドで完全に理解してください。(Calicoくらいしか使ったことない)

kubelet

kube-scheduler によって紐付けられた(スケジュールされた)Podを kubelet が認識して、そのPodを自身のNodeで起動させる。また、実行しているPodの監視・管理も行う。

kube-proxy

kube-proxy はKubernetesのServiceオブジェクトを元にルーティングを行う。実体はiptablesのルールを発行し、パケットの制御を行っている。

Kubernetes道場 24日目 - Kubernetesの各コンポーネントについて - Toku's Blog

10. Configuring kubectl for Remote Access

Configuring kubectl for Remote Access

adminユーザで、kubectlを実行するために、kubeconfigファイルを生成します。接続するKubernetes API Serverとしては、Kubernetes API Serverの前段に配置したLBを指定します。

11. Provisioning Pod Network Routes

異なるWorkerノード上で動くPodが通信できるように、経路情報を設定します。ここでは、それぞれのWorkerノードに対して、PodのCIDRとノードの内部IPアドレスを紐づける経路情報を定義します。

NAME NETWORK DEST_RANGE NEXT_HOP PRIORITY

default-route-081879136902de56 kubernetes-the-hard-way 10.240.0.0/24 kubernetes-the-hard-way 1000

default-route-55199a5aa126d7aa kubernetes-the-hard-way 0.0.0.0/0 default-internet-gateway 1000

kubernetes-route-10-200-0-0-24 kubernetes-the-hard-way 10.200.0.0/24 10.240.0.20 1000

kubernetes-route-10-200-1-0-24 kubernetes-the-hard-way 10.200.1.0/24 10.240.0.21 1000

kubernetes-route-10-200-2-0-24 kubernetes-the-hard-way 10.200.2.0/24 10.240.0.22 1000

ちなみにKubernetesのネットワークモデルを実装するその他の選択肢は、公式ドキュメントに書いてあるようです。

12. Deploying the DNS Cluster Add-on

DNSアドオンをデプロイすることで、クラスタ内のアプリケーションに対して、DNSベースのサービスディスカバリを提供できます。導入自体は、コマンド1行でできるらしいです。

1	kubectl get pods -l k8s-app=kube-dns -n kube-system

さいごに

図や説明などは適宜追記していきます。次回は残りのテストを行い、Kubernetesクラスタの動作を確認します。
ちなみに手書きのメモはiPad mini 5で書きました。GoodNotes5というアプリです。有名だけど、意外と使ってない人もいるので、布教していきたい。

iPad mini 5と買ってよかったアクセサリー

概要先月、iPad mini5を衝動買いしました。衝動買いとは、往往にして失敗しますが、今回は成功しました。iPad自体の記事はいろいろあるので、今回は周辺アクセサリーで買ってよかったものをまとめます。ボーナス入る読みで、衝動買い...(続く)

<このシリーズ>

「Kubernetes the hard way」を図で理解したい -前編-

「Kubernetes the hard way」を図で理解したい -後編-

Nishipyはじめに前編の続き、後編です。Kubernetes the hard wayといやつをやってみたときのメモを残します。また各章に対して、適宜図などをつけてみます。PrerequisitesI...(続く)

以上.