ソフトウェアエンジニアリングを10年以上やってきて、つまりはその年月の間ずっと技術を学習し続けたのだけど、
最終的に行き着いた学習方法はとりあえずやってみて、必要と感じた部分をピンポイントでググって調べる。
ある程度身についたら入門本やwalkthrough系の本を1冊丸々読んで欠けていたり自学で盲点となりやすいポイントを掬う、というものになった。
というわけでこの本はそのKubernetesのwalkthroughになる。その目的としては非常に優秀で良い本だった。
以下メモ
1章
3つの革命。
- クラウド
- DEvOps
- コンテナ
メインフレーム → クラウド 一周してきた
P6
一見どう見えようとも、それはつねに人間の問題である。
P14
Kubernetesによる抽象化でクラウド固有の詳細が隠されるため、...
これは嘘。ALBを使うにはalb-ingress-controllerを使う必要があるし、そうでなくてもLBへ証明書を割り当てるためにALB専用のアノテーションをつける必要がある。
Kubernetesが得意としないものもある。例えばデータベース。あとFaaSのほうがよいものもある。
P 18
個々の開発チームでは、チームが提供するシステムやサービスの健全性を担当する運用専門家が少なくとも1名は必要になります。
やっぱそうよなあ。
P 19
開発者生産性光学(Developer Productivity Engineering, DPE)
なるほど、従来の運用専門チームに変わる、分散化した運用者のために共通ツール・ノウハウを作って支援する部署)。
2章
P28
これと比較すると、公式のRubyコンテナイメージはサイズが1.5GiBで、Goイメージの約250倍もあります。
草。その通りだねとしか言えない。
P33
結構minikubeのセットアップには苦労した。特にdriverがvirtualboxとkvmとnoneの3種類あって、標準は遅いがbattle proofのあるvirtualboxなのだけど、ubuntuの最新virtualboxが6.x系ナノに対してminikubeの互換バージョンは5x系らしく、結局noneにした(パフォーマンスも良さそうなので)。
macでどうするかはまたひと悶着ありそう。docker for macのkubernetes使う手もあるそうだけど、kubernetes公式的にはminikube。なんとなくminikubeのほうが良さそうな気がするが手軽なのはdocker for macか？
3章
P41
何もない状態からKubernetesを本番の設定で運用し始めるためには、エンジニアの給与で約100万ドルが必要になると推定しています(「それでも目的を達成できないかもしれません」)。
これが西海岸のバブル給与だとしても、オンプレでやる場合日本円でも数千万はかかるというのは納得感がある。
P42
ぐだぐだと中小企業ではKubernetesを運用するのは高コストだからマネージドサービス使えと数ページ使って書かれている。
P43
著者らだけでなく、本書のためにインタビューした多くの人々の経験でも、Kubernetesを実行する最善の方法はマネージドサービスです。以上
P44
GKEのオートスケール
EKSはデフォルトではできない機能で羨ましいところ。
P45
とはいえ、マネージドKubernetes市場では最後発であるため、EKSがGoogleやMicrosoftのサービスに追いつくまでにはまだじかんがかかるでしょう。
AWSさんもっと頑張ってくれー (・∀・ )っ/凵⌒☆ﾁﾝﾁﾝ
P51
「実行するソフトウェアを減らす」という哲学には3本の柱があり、いずれも時間をうまく使って競争相手に打ち勝つために役立ちます。
1. 標準のテクノロジを選ぶ
2. 差別化につながらない面倒な作業はアウトソーシングする
3. 長続きする競争優位性を生み出す
Rich Archbold
これいいね。
P54
それがAzure Container Instances やAWS Fargateなどの、いわゆるクラスタレスサービスです。
この呼称初めて聞いた。いいね。
P63
一般にDeploymentはユーザーが直接触るけどReplica Setを直接触ることは少ない
ほえー確かに。これ言われるまでPod, Replica set, Deploymentは3セットで人に説明していたわ。
P69
実際、ServiceとIngressはどちらも、クラウド型のロードバランサを自動的に作成できます。
この2つが似ているという認識はやっぱり正しいみたい。
P73
helmの辺りはなかなか刺激的だった。これなら自分でもchartを作れそうと思う。
P82
gRPC probe
それが簡単だからと安易にkubernetesの仕様へgRPCのプロトコルなどを組み込まなかったのはさすがの判断。OSSとして抑えなければいけない中立性をよくわかっている。
P83
readiness probeとliveness probeの違いというか使い分けがよくわからない。livenessが生きているか死んでいるかでこれがfalseになるとコンテナをdeleteする、readinessはそのコンテナが受付可能かどうかでserviceから切り離すかどうかを示す、であっているかなあ。
この動作が特に重要となるのはゼロダウンタイムアップグレードの場合です(詳細については13章の「13.2 デプロイ戦略」を参照)。
参照先をみてもreadinessのことが書かれていない。たぶんデプロイ戦略中の切り替えの判断にreadinessを使っているということだろうと思うのだけど。
P88
デフォルトのNamespaceは、間違いを起こしやすいため使用してはなりません。
そうなのか。
Kubernetesのベストプラクティス：名前空間を使用した整理| Google Cloudブログ
たしかにこちらにもそう書いてある。
P88
Serviceのアドレス
なるほど、Serviceだけ？がNamespaceの壁を超えられるのか。
カプセル化、というかインターフェイスはtcpに限定しているkubernetesの思想的には一貫している。
P89
ポッドの実行数のハードリミット。ただこれだと問答無用でエラーが発生するのでポッド実行のスロットリング目的としては不適か？
いやでもjob経由ならキューに積まれそう。
P92
ほとんどのマネージドKuberentesサービスには、コンテナのCPUおよびメモリ仕様状況を時間の経過に沿って表示する、何らかのダッシュボード機能が用意されています。
みてるかー、AWS EKSチーム見てるかー！！！
P93
Vritical Pod Autoscaler リソース要求の理想的な値を算出するのに役立つ。
単なるオートスケーリングだけじゃなくて実際にリソースを監視してリソースの最適なlimitを決めるのに使えるのか。便利。
P94
優れた経験則として、ノードは典型的なPodを少なくとも5つは実行するのに十分なサイズとする
fmfm
P97
kube-job-cleaner
なるほど、これは便利。
P98
Spot Instanceの利用
これ魅力的なのはわかるけどこれを使う設定がわからない。
[EKS] [request]: Spot instances for managed node groups · Issue #583 · aws/containers-roadmap
Managed Node Groupでもサポートされていないし、これを使うとなるとアンマネージドになるのが辛い。
P102
Descheduler
ポッドの偏りを解消するコントローラ
P109
ベストプラクティスでのシングルテナントの推奨
これには賛成しかねる。 マルチテナントとシングルテナント, kubernetesで検索して出てくるスライド資料参照
P111
ベアメタルサーバ
どっかで聞いたような話だ。
P117
Copper, manifestのlinter
これはCIへ組み込むと良さそう。
P 128
kubectlの--watchコマンド
これ知らずにwhile sleepでループさせてた。参考にしよう。
P129
本書ではずっと、コードとしての宣言的インフラを使用する重要性を強調してきました。そのため、「命令的なkubectlコマンドの使用は推奨しない」という主張が驚かれることはないでしょう。
なるほど。たしかにcreateやdeleteはローカル環境でやる時以外は控えたほうが良いかも。
P134
コンテナへのアタッチ
用途がよくわからない。dockerなどと一緒だとしたら標準入力などを与える場合はこれが必要？
kubespy
リソースの変更を監視できるツール。
kubectl get --watch もよいがこれも便利そう。
ただkubernetesの手頃なdashboardがあれば不要？
P136
kubernetesクラスタのトラブルシューティング(主にネットワークなど)のための便利コマンド
kubectl run nslookup --image=busybox:1.28 --rm -it --restart=Never --command -- nslookup demo
P140
コンテキストはクラスタ、ユーザー、ネームスペースの組み合わせのこと
P155
本番環境でコンテナをデプロイするときは、latestタグの使用を避けるべきです。実行中のイメージのバージョンを把握することが難しく、また適切なロールバックが困難になるためです。
ああ、よく知ってる。
P163前後
ポッドのセキュリティ。非常に面倒くさいことだけはよくわかった。
P166
永続化ボリューム
そういえばeksでefsって使えるのかなと思って調べてみたら、この永続ボリュームの機能で使えるっぽい。
P175
Labelは内部的にも酷使されるためかなり厳しい制限がある。
具体的にはlabel名は63文字まで、ただしdnsサブドメイン形式での最大256文字までのprefixが認められる。
prefixとlabel名本体は/で区切られう。
labelの名前と値に使える文字は-_.alphanumのみ。
P176
こうした Affinity にはハードとソフトの 2 種類があります。残念ながらソフトウェアエンジニア
は必ずしも命名の才に恵まれているわけではないため、 Kubernetes の場合、これらは次のように
呼ばれています。
● requiredDuringSchedulingIgnoredDuringExecution (ハード)
● preferredDuringSchedulingIgnoredDuringExecution (ソフト)
草
P184
StatefulSet
名前に反してDeploymentの各Podへindexがついただけのような微妙なリソースタイプ。
StatefulSet では、 PersistentVolumeClaim を自動的に作成する VolumeClaimTemplates を使用
して、紐づく一連の Pod のディスクストレージも管理できます
と思ったらやっぱり永続化に関する機能というかデフォルトの振る舞いもあるっぽい。
P186
CronJob マ ニ フ ェ ス ト で 注 目 す べ き 重 要 な フ ィ ー ル ド は 、 spec.schedule と spec.job
Template の 2 つです。 schedule フィールドはジョブが実行されるタイミングを指定するも
ので、 Unix の cron ユーティリティと同じ形式( https://en.wikipedia.org/wiki/Cron )を使用し
ます † 4 。
本書く人ですらWikipediaを参照する程度にcronのフォーマットの仕様はwebに明記されていないんよな。
man結果を安定的にホスティングするセミオフィシャルなサイトとかあったらいいんだけど。
P190
監訳注: 2016 年に Operator を提唱した CoreOS 社(現在は IBM 社の一部)は、ブログ( https://coreos.com/blog/introd
ucing-operators.html )で Operator を「アプリケーション固有の運用ナレッジがプログラミングされたカスタムコントロー
ラ」と言っています。そのため、このサンプルは Operator ではなく Kubernetes コントローラと呼ぶほうが一般的かもしれ
ません。
P192
証明書ってIngressで設定できたんだへーと思ったら
tls.secretNameからACMに証明書をインポート・問題＃1084・kubernetes-sigs / aws-alb-ingress-controller
ACMでもできるようになりつつあるらしい。
これでalb-ingress-controllerがちゃんと取り込まれたらAWSでもKubernetesとクラウドサービスの結合度はかなり高くなるなあ
P204
envFromを使用することで、COnfigMapからすべてのキーを取り込んで環境変数に変換するための簡単な方法が用意されています。
これは便利。
P205
configMapからコンテナ上のファイルへそのまま書き出す方法が書かれている
P215
SOPS
現状parameter storeとexternal-secretsで同期しているから不要？
でもhelm-secretsを使う利点もあるかもしれない。
SOPS、読み進めるとこれ12 factors appに反しているな。
あとterraformからのパラメータの引き渡しも難しい。やっぱりSOPSは微妙な気がする。
P222
マルチテナントについて
これはたしかに最も安全なアプローチですが、クラスタを追加していくことにはトレードオフもあしります。どのクラスタもパッチ適用や監視の対象とする必要があり、多数の小さなクラスタは少数の大きなクラスタに比べて実行効率が劣る傾向もあります。
うん。だからterraformのmoduleを使用してなるべく一つのアプローチで一気に管理できるようにしようとしている。
P223
viewロール
これいいね。readonlyロール
P249
values.yaml
なるほど、これがあればhelm-install.shはもっとよく書けそう。
P255
helmfile
これ、argo cdと競合するので使うべきか悩む。
P257
ksonnetの最も重要な点は、プロトタイプという概念を導入していることです。これは
Kubernetes リソースのあらかじめ記述された組み合わせで、よく使われるマニフェストのパ
ターンを、スタンプで押すように手軽に利用できるようになります。
これは魅力的。
P 260
kubeval
これ読む限り、こいつがやってくれるvalidationはkubectlがやってくれるものと完全に等価？
ユーザーグラウンドでこのプロパティの値はこの範囲、のような指定はできないのかも。
そういうのはconftestか。
P263
13章開発ワークフローはローカル環境で高速に開発サイクルを回したいときのツールらしい。
なかなか難しいトピックになってきた。
Draft, Skaffold, Telepresence
この辺り、部内でk8sを広めていくためには必要になってくるかー。
P269
BGデプロイをlabelでする
これをなんらかのツールなどで支援できないとなかなかつらい。オペミス発生しそう。
カナリアデプロイにはIstioが必要
P270
Helmのフック機能
これいいなー。
P276
14.2 おすすめのCDツール
weave fluxもargo cdも書かれていない？
時期が2年近く前であることを考えると必然か？
P279
と思ったらfluxはこっちにあった。
P294
ユーザがハッピーでなければ 9 の数に意味はありません。
―― Charity Majors ( https://red.ht/2FMZcMZ )
いい言葉だ。
15章、16章は流してしまった。
また興味が湧いたら読み直す。
すぐやること
- インスタンスサイズは4つより2つのほうが良さげ
- defaultのネームスペースは危険なので使わない
- Copper - manifestのlinter
- envFromで変数の羅列をやめる
- deschedulerは大定番っぽいので基本入れる
- conftest, kubevalは基本入れる(これはkubernetes meetup #29から)
- 管理者以外にviewロールで権限を付与する
- velero - これもmeetup #29からでもあるけど、とりあえずsnapshotを取っておくだけでもかなり有用
