普通の休日の翌日

5時に寝て10時に起きた。昨日は夕方に2-3時間寝てたのでその分、夜に調べものをしていた。休みたい気持ちもあるけど、調べるものが多過ぎて全然時間が足りない。

bizpy 勉強会の資料作り⌗

昨日 の続き。昨日サンプルコードを実装したので、その設定や要点を 資料 に作成した。現時点で Python で Slack のインテグレーションをやってみる勉強会 #2 の参加者は10人。連続シリーズは回を重ねるごとに減っていくものなのでこんなもんかな。あともう1回やったら終わりにする。

udemy: Kubernetes入門⌗

友だちから udemy の k8s のコースがよいと聞いたんだけど、そのコースはいまは提供されていなくて、せっかくなので適当に検索してヒットした Kubernetes入門 を受講することに決めた。本当は英語の本格的なコースを受講した方がよいのだろうけど、余裕のあるときはそれでいいけど、いま数日で概要を把握して使えるようにしたいので日本語のコースにしてみた。

• Udemy の Learning Docker and Kubernetes by Lab がとてもよい
• Docker, Kubernetes 学習とツールとコンピュータサイエンス

昨日インストールした minikube のクラスターを使って「Kubernetes入門」のセクション1からセクション5までやった。だいたい半分ぐらい。所感としては、全く何も知らない人には要点をかいつまんで教えてくれるのと、最初に覚えるとよい基本的な CLI のコマンドとその振る舞いや設定を紹介してくれるのでよかった。初めて k8s に挑戦する自分にとってはちょうどよいレベル感だった。全体像の概念を捉えてコンテキストに沿って順番にハンズオン形式で学習していくスタイル。nakamasato/kubernetes-basics を使って自分でも CLI でコマンドを打ちながら進めてみた。yaml ファイルを定義するのもこれはこれで面倒だけど、この辺は慣れの問題かな？とも思う。いくつか学んだことを整理しておく。

セクション1 Introduction⌗

k8s には2つのコンポーネントがあり、これを k8s クラスターと呼んでいる。

• Control Plane (API サーバー)
• 複数の Worker (Kubelet)

yaml で設定する Desired State (理想状態) と呼ばれる設定が登録されると、Control Plane の API サーバーと Worker の kubelet が通信してそれを実現しようとする。pod とは k8s のデプロイの最小単位となる。コンテナ、ポート、レプリカ数などを設定する。pod をそれぞれの Worker にデプロイしたり、Worker がダウンしたときに別の Worker で起動させたりする。

セクション2 Kubernets 概要⌗

k8s はコンテナ化したアプリケーションのデプロイ、スケーリング、管理を行うためのオープンソースのコンテナオーケストレーションシステムである。

• コンテナ
  • 独立した環境でアプリケーションを実行する仕組み
  • コンテナの実態はプロセス
  • Kernel Namespaces を利用し、プロセスID、ネットワークインターフェース、リソースなどを分離してコンテナ間で干渉しない
  • ホストマシンへの依存度を最小化してアプリケーションをどこでも実行可能にする
    • 従来のやり方の最大の違いはライブラリがホストマシンにインストールされるのではなく、コンテナの内部にインストールされる
• オーケストレーション
  • デプロイ、スケーリング、管理などの仕組み

1つのアプリケーションは複数のマシン上で動かすことで可用性を高めたいが、コンテナを動かすために考えることが増えていくと管理コストも増えていく。コンテナオーケストレーション機能により次のようなシステム管理者が行っていたことが自動化される。

• デプロイメント
• スケジューリング
• オートスケーリング
  • 負荷に応じてコンテナ数やマシン数を増減させる
• ネットワーク
• リソースマネジメント
• セキュリティ
  • ネットワークポリシーやリソースの権限定義

k8s クラスターの構造は次になる。

• Control Plane
  • api: kubelet と通信するサーバー
  • etcd: 設定などを格納するキーバリューストア
  • shed: kube スケジューラー
  • c-m: コントロールマネージャー
  • c-c-m: クラウドプロバイダと api 連携する
    • ローカルで使うときは必要ない
• Worker ノードはコンテナランタイムをいインストールしておく必要がある
  • kubelet は Control Plane と通信するためのエージェントとして動作する

一番需要なこととして、k8s は理想状態と現実状態を比較して、理想状態に近づけようとする。app.yaml の理想状態を kubectl を用いて api サーバーを介して etcd に格納する。現実状態は kubelet から api サーバーを介して etcd に格納される。c-m は理想状態と現実状態のチェックを行い、異なっていれば理想状態に近づけることをしていく。

セクション4 kubectl⌗

minikube で最初に起動しているのは Control Plane を起動していることが理解できた。

$ minikube start
$ kubectl config current-context
minikube

同時に ~/.kube/config に kubectl の設定も追加される。minikube という名前でクラスター、ユーザー、コンテキストが設定される。

リソース一覧の確認。

$ kubectl api-resources

出力フォーマットも様々。例えば、デフォルトの表示は次になる。

$ kubectl get node
NAME       STATUS   ROLES                  AGE     VERSION
minikube   Ready    control-plane,master   7m21s   v1.22.2

$ kubectl get node -o wide
NAME       STATUS   ROLES                  AGE     VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
minikube   Ready    control-plane,master   8m38s   v1.22.2   192.168.49.2   <none>        Ubuntu 20.04.2 LTS   5.11.0-38-generic   docker://20.10.8

より詳細な情報をそれぞれのフォーマットで表示する。

$ kubectl get node -o json
$ kubectl get node -o yaml

namespace を確認する。

$ kubectl get namespace
NAME              STATUS   AGE
default           Active   10m
kube-node-lease   Active   10m
kube-public       Active   10m
kube-system       Active   10m

namespace を指定して pod 一覧を取得する。

$ kubectl get pod --namespace kube-system
NAME                               READY   STATUS    RESTARTS      AGE
coredns-78fcd69978-qxqbn           1/1     Running   0             11m
etcd-minikube                      1/1     Running   0             11m
kube-apiserver-minikube            1/1     Running   0             11m
kube-controller-manager-minikube   1/1     Running   0             11m
kube-proxy-g55hg                   1/1     Running   0             11m
kube-scheduler-minikube            1/1     Running   0             11m
storage-provisioner                1/1     Running   1 (10m ago)   11m

グローバルな CLI のオプションを確認する。

$ kubectl options

ノードの詳細を表示する。

$ kubectl describe node

describe は名前の接頭辞を指定できるので namespace ならこんな感じに実行できる。

$ kubectl describe namespace kube-

セクション5 Kubernetes リソース⌗

pod とは k8s 上のデプロイの最小単位である。

• 1つまたは複数のコンテナをもつ
• ネットワークやストレージを共有リソースとしてもつ
• コンテナの実行方法に関する仕様をもつ

pod が使えなくなった場合に他のノードにデプロイされることもある。1つのアプリケーションを複数の pod でデプロイすることが多い。なるべく複数のアプリケーションを1つの pod に入れない。個別の pod を直接操作しない。

共有コンテキスト

• 同一 pod 内のコンテナは同じストレージにアクセスできる
• 同一 pod 内のコンテナは ip アドレスとポートを含むネットワーク名前空間を共有する

k8s オブジェクト

• クラスタの状態を表現する
• 2つのフィールドをもつ
  • spec: 理想状態 (desired status)
  • status: 現実状態 (current status)

pod の作成は k8s オブジェクトを作成している。オブジェクト作成時の必須フィールドが4つある。

• apiVersion
• kind
• metadata
• spec

namespace は同一クラスター上で複数の仮想クラスターの動作をサポートする。

• 仮想クラスターとは、物理的には同じマシンで動いているかもしれないが、仮想的に環境を分離している
  • 1つのクラスターを論理的にわける
  • チームや部署ごとにわけて使い分けたりすることも多い

namespace を使うメリットは次になる。

• pod やコンテナのリソースの範囲設定
• namespace 全体の総リソース制限
• 権限管理

初期の namespace として4つあるが、初心者は最初の2つだけをまず覚えておく。

• default:
• kube-system:
• kube-public:
• kube-node-lease

namespace と cluster の違い。

• Namespace-scoped リソース
  • namespace に属しているリソース
• Cluster-scoped リソース
  • クラスター全体で使われるもの

次のコマンドで確認できる。

$ kubectl api-resources --namespaced=true 

namespace の作成

$ kubectl create namespace my-namespace

ワークロードリソースとは複数の pod を作成・管理するためのリソース。ワークロードリソースは pod テンプレートを使って pod を作成する。

• ReplicaSet
  • 常に指定したレプリカ数の pod を保つ
• Deployment
  • ローリングアップデートやロールバックなどのアップデート機能を提供
  • ReplicaSet のロールアウト
  • 不安定な場合の前のバージョンへロールバック
  • 使用頻度が高い
    • ほとんどのアプリケーションは Deployment で管理
• Secret
  • 機密情報を保存・管理し、Pod から参照可能
  • 主な使用方法としてコンテナの環境変数の設定
    • アプリケーションの DB のパスワードなどに使う
• Service
  • pod の集合を抽象化して公開する
    • pod の集合に対する DNS 名
    • pod の集合に対する負荷分散