【読書メモ】 k8sで実践するクラウドネイティブDevOps
読書メモ
↑の書籍の自分用読書メモ
現在の知識からの差分もしくは知っていても整理できていなかった部分を中心に
途中、自分で調べた補足なども入っているので本の内容でない部分もあり
chapterごとに気になった点
3つの革命
- クラウドの創造
- コンピュータを買うのではなく処理能力を買う
- IaaS＝ITインフラを電気や水道のようなコモディティとして利用できる
- undifferentiated heavy lifting（差別化に繋がらない面倒な作業）をこなしてくれるのがマネージドサービス
- おそらくWerner Vogelsさん発の言葉
- ETech: Amazon CTO Werner Vogels on Building Web-Scale Computing - ReadWrite
- DevOpsの黎明
- 20世紀中頃、ソフトウェア開発もコンピュータの運用も非常に専門性が高く重なり合う部分が無かった
- 新機能をリリースしたい開発者と安定性・信頼性を上げたい運用者は対立しがち
- クラウドの登場で状況が変化
- システムの運用に必要となる専門事項（障害からの復旧、バージョンアップグレード）をシステムの設計、アーキテクチャ、実装から切り離せない
- システムは自社開発のソフトウェアだけで完結せず、ソフトウェアを書く人はシステム全体との関連性を理解する必要がある。運用者はソフトウェアが機能する仕組みを理解する。
- クラウドが極めて大規模であり、DevOpsの動向はコラボレーション型でコード中心の性質を帯びていることから、運用はソフトウェアの問題へと変容している
- コンテナの到来
- これまでの状況
- 構成管理を使うためにはあらかじめ、言語によって異なるランタイムを入れる必要がある
- 仮想マシンイメージは重くて運用に適さない
- 運用の観点からすると、こうした多種多様なパッケージを管理するだけでなく、それを実行する一連のサーバも管理する必要性がある -> 大変
- SeaLand社はコンテナを用いて商品を従来より遥かに安く船舶輸送することによって成功を収めた。これをテクノロジ業界が取り入れたものがコンテナ
- 仮想化されたワークロードは同等のコンテナと比較して実行速度が30%遅くなる（それほどコンテナが軽量かつ効率よくリソースを使用しているということ）
- 運用チームとしても様々な種類のマシン/アーキテクチャ/OSを保守する代わりに、コンテナオーケストレータを実行するだけで良い
- Kubernetesは、自動化、フェイルオーバ、集中ロギング、監視など、非常に優秀なシスアドが行うであろうことを実行する
- クラウドネイティブの特性
- 従来の運用の大半は他のチームに移譲するべき
- そのためにはDevOpsエコシステムを構築およびサポートする中央チームが必要
- チームの機能は運用ではなく開発者生産性工学(DPE)
- 純粋なDevOpsモデルは中小でこそ機能するが、組織が成長するにつれ、インフラや信頼性に関する専門家が中央チームに引き寄せられていく
- ソース：The human scalability of “DevOps” - Matt Klein - Medium
- 75人を超える頃には確実に中央インフラチームが設置され製品チームに必要な共有の基盤を構築し始める
- それでもいずれ回らなくなってくるので、そのときはSREを個々の開発チームに配属する
- ソフトウェアエンジニアと運用エンジニアの明確な区別はなくなる
- これまでの状況
Kubernetes環境の選択
- Kubernetes自体の運用については取り扱わないので、知りたい場合には別書籍読んでね
- コントロールプレーン
- kube-scheduler
- 「全てのpodの情報を取得しNodeにassignされていなければする」という挙動を取っていると思われがちだが、実際にはControllerがactualとdesiredとの差分を見てqueueに追加、schedulerは継続的にそれをpopし配置する
- How does the Kubernetes scheduler work? - Julia Evans
- cloud-controller-manager
- kubernetesのリリース周期とクラウドベンダー側の対応の周期が合わないため、kube-controller-managerから切り出した
- kube-scheduler
- セルフホスティングは特別な理由がない限りやめておけ！！辛いぞ！！！
- 近年では、「納品後すぐに稼働できる状態で引き渡される」というターンキー方式が成長してきている
- Run Less Software(=実行するソフトウェアを減らす)
- ソース: Run less software | Inside Intercom
- 三本柱
- ↑の哲学に従い、マネージドKubernetesを使用することを推奨
- 基本はGKE、もし単一クラウドプロバイダーに縛られることなく24時間のテクニカルサポートを受ける場合にはHeptioがおすすめ
リソースの管理
- CPUをlimit以上に使おうとするときにはスロットル処理の対象となる
- gRPCのヘルスチェックには、標準のみだと難しいのでgrpc-health-probeツールを利用する
- コンテナが起動していれば、podのステータスはRunningになるが、READY列はカウントされない
- ファイルベースのReadiness Probeはトラブルシューティングに便利
- 例えば、/tmp/healthyのファイルを削除することで、Serviceから除外する
- （ただし、labelコマンド使った方が楽なんじゃないか説）
- Readiness Probeが成功を返す状態がminReadySeconds続かないとServiceにつながらない（デフォルトはゼロになっている）
- namespaceでネットワークトラフィックを管理する場合にはNetwork Policy使う
- ResourceQuotaでnamespaceごとにリソース量を制限できる
- LimitRangeリソースで、すべてのコンテナについてデフォルトのリソース要求と制限設定できる
- 優れた経験則
- ノードのサイズは典型的なpodを少なくても5つ実行するのに十分なサイズ
- 取り残されたリソースの割合を10%程度以下に維持する
- 大きいノードの方が費用対効果が高い(のでノードあたりのpod数は10個から100個目標にする)
- Jobリソースを削除するためにTTLを設定できる
- まだアルファなので代わりにThird Partyのkube-job-cleanerが使えそう
- Kubernetesのannotationに所有者情報を入れるべし
- 組織のドメイン名をprefixに付けるべき
example.com/owner: "Customer App Team"
- 幾らかの割合でプリエンティブインスタンスを使うようにすることで費用削減
- スケジューラはノード間でpodを移動しないため、アンバランスな配置になってしまうとが多い
クラスタの運用
- ベンダやサービスがCNCFの期待するCertified Kubernetes標準を満たすかを示すマーク及びロゴがある
- Sonobuoyを使って「クラスタが適切に設定され最新状態である」ことを確認できる
- k8sguardはクラスタの問題をチェックしてくれるツールだが2年動きが無いらしいの代替のツール有れば欲しい
- kubernetesのChaos Engineering
- Chaoskube: ランダムにpodを落とす
- kube-monkey: 対象となるDeploymentの何%までを落とす
- powerfulseal: ほとんどのシナリオを網羅できる
Kubernetesの強力なツール
- kubectlの自動補完はTABキーを使って行う
- 出てこない場合には、有効になっていない可能性があるので、
kubectl completion -hを打ってヘルプ見る - （…自動補完の設定してたものの、どうやって補完するんだ…？まあいいや、kube-prompt使おーとなってて完全に思考停止だった）
- 出てこない場合には、有効になっていない可能性があるので、
- kubectlには
--watchオプションがあり、ステータスが更新されると更新情報が表示れる - 基本、命令的モード（create,edit...）は使うべきでは無いが、マニフェストの生成役に立つ。--dry-runと-o yamlを使う
- kubectl diffは良いぞー（分かる）
- kubectl logsのオプション
- tailで直近のみに絞り
- --followでストリームとして随時表示
- kubespyによってリソースの細かい時系列イベントの監視が出来る
- busyboxと--rm、--restart=Neverを用いて調査できる
alias bb=$kubectl run busybox --image=busybox --rm -it --restart=Never$
- バイナリのみ配置した軽量コンテナで普通に色々なコマンド叩きたいことがある。そのきはdockerビルド時にマルチステージビルドの要領でBusyboxコンテナから
/bin/busyboxを持ってくるCOPY --from=busybox /bin/busybox /bin/busybox
- squashというツールでライブデバッグできる
- kubectl v1.14から、--selectorフラグを使ってラベルセレクタに一致する複数podのログを取得できるように
コンテナの実行
- ダイジェストを使ったイメージ指定が確実
- cloudnative/demo@sha256:${ダイジェスト}
- 非rootとしてコンテナを実行
- root実行はprinciple of least privilegeに反する
- バグを利用して悪意のあるユーザがプログラムを乗っ取ることも考えられる
- securityContext.runAsUserで実行ユーザのUIDを指定
- Linuxシステムの多くでは、最初の非rootユーザにUID1000が割り当てられるめ、一般的にコンテナのUIDは1000以上の値を選択（ユーザが存在していなくても良い）
- Dockerfile内で実行ユーザを指定できるが、runAsUserフィールドを設定するが良い
- runAsUserで指定したUID → Dockerfileで指定したUID → root
- セキュリティを最大限に高めるためにはコンテナごとに別のUIDを選択する必要がるが、同じデータボリュームにアクセスする場合は同じの方が良い
- コンテナが自分自身のファイルシステムに書き込むことを防止すreadOnlyFilesystemを使うのもよい（ファイルの書き込みをしないコンテナのみ）
- setuidバイナリが含まれる場合には、実行ユーザをroot以外にしていてもroot権限獲得する可能性がある。これを防ぐには、allowPrivilege Escalationをfalseにる。
- コンテナのデフォルトのcapabilityはかなり寛容なので、最小権限の法則を鑑みると必要に応じてdrop, addする必要がある
- セキュリティを最大限に高めるためには、全てのcapabilityを削除し、必要に応じ特定のcapabilityのみ追加する
- podレベルでのsecurityContextの設定が可能なので、そこで権限昇格を無効にし、てのcapabilityを削除するのがベスト
- クラスタレベルでpodのcapabilityを設定することも可能で、それにPodSecurityPolicyを使用する
- プライベートレジストリからImageをpullする場合には、
imagePullSecretsフィールドを使って設定する
Podの管理
kubectl get pods -l app!=demoやkubectl get pods -l app in(staging. production)のようなラベルクエリを書くことも可能（Serviceリソースは等価クエリのみ）- LabelとAnnotationの違い＝リソースを識別するしないか（どちらもkeyvalueのメデータ）
- Labelの目的は、関連するリソースのグループを選択すること
- Annotationは識別には用いられず、Kubernetesの外部のツールやサービスが利用る
- PodAffinityはスケジューラの自由を制約するため、アプリケーション間でトレードフが発生する -> 切り札として使うように
- TaintとTolerationは特定のpodが特定の種類のノードの問題を許容できるようにすこともある
- Nodeでネットワークが利用できなくなったとき、Kubernetesは
node.kubernetesio/unreachableというTaintを自動的に追加する - 通常はNodeのkubeletがすべてのpodをnodeから退去させる
- ネットワークが合理的な時間内に復旧することを期待して、一部のpodはそのまま実させておきたいケースがある
- これを実現するためには、unreachableというTaintに一致するTolerationをpodに追加しておく
- Nodeでネットワークが利用できなくなったとき、Kubernetesは
- Podは通常コントローラによって管理される
- StatefulSetはPodを特定の順序で起動及び終了させる
- Redis, MongoDB, Cassandraなどの分散アプリケーションは独自のクラスタ作成することから、クラスタリーダを予測可能な名前で識別できる必要がある
- 個々のPodは自身がredis-0で実行されているかを確認し、もしされているのでればクラスタリーダとして、そうでなければredis-0と連絡を取ることでクラスタ参加できる
- 0から順に起動するため、クラスタリーダが起動した後に他のpodを起動させるこを保証できる
- 終了時は逆に0を最後にシャットダウンさせる
- Headless Serviceを使えば、
redis-0.default.svc.cluster.localな各podが認識できるDNS名が与えられる
- StatefulSetはPodを特定の順序で起動及び終了させる
- アルファの機能で
PodPresetというのがあり、Mutating Admission Webhookを易に使用できるようなリソースのようで、定義した設定を個々のPodの設定とマージできる - オペレータの作り方
設定と機密情報
- ConfigMapの設定で楽なのは
kubectl create configmap demo--from-file=config.yaml --dry-run -o yaml - configMapの情報は環境変数として読み込むこともできれば、volumeとして扱うことできます
- ConfigMapの設定変更はすぐに反映される
- Secretの読み取りや編集はRBACによって制御される。etcdにアクセス権限のあるユザは見れるかというと、そうではなくデータは保存時に暗号化されているため見れない。
- 機密データの運用については、一旦SOPS（secrets operation）を試してみて不足がるようならVaultのようなツールを試すべき
セキュリティとバックアップ
- ClairはコンテナスキャナでCDパイプラインに統合してデプロイ前にテストすることもきる
- 他にも、TrivyやAchore Engineなどのコンテナスキャンツールが存在する
- レプリケーションはバックアップではない
- 例えば、クリックする場所を間違えてボリュームを削除してしまうといった事故からってくれない
- なのでバックアップを取る必要性がある
- Veleroはクラスタの状態と永続データをバックアップ及び復元できるツール
- Kubernetes DashboardはConfigMapやSecretの内容も表示できるのでDashboardに対する制限は厳しくしなければならない
- インターネットに公開してはならず、代わりに
kubectl proxyを利用する - 要らないなら実行しなくても良い
- インターネットに公開してはならず、代わりに
Kubernetesアプリケーションのデプロイ
- Helmについての記述が多かったが基本的には公開されているリポジトリ以外では使わいのでパラ見
- kustomizeはv1.14からkubectlに入ったみたい
- Conftestというツールでマニフェスト検証ができるので、CDパイプラインに追加しても良さそう
- バージョンアップしたときに変更する必要性があるかをテストできる
開発ワークフロー
- Skaffoldって変更を検知して、ファイルをユーザの代わりに自動的にデプロイするのすごい。コンテナレジストリへの明示的なPushが要らない。
- Terepresenceはローカルマシンをリモートクラスタに参加させることができる、つまデプロイが要らない
Kubernetesにおける継続的デプロイ
- コンテナベースのCDパイプラインツールを使う場合には、各ステップのコンテナをできるだけ小さくする
Observabilityと監視
- ブラックボックス監視の限界
- メトリクスの導入
- 「なぜか」という疑問の解決に役立つ
- 問題の予測に役立つ
- トレーシング
- Obeservability Pipeline
- Kubernetesにおける監視
- ブラックボックス型チェック
- 内部ヘルスチェック
- より高度なReadinessProbeとするなら、「このアプリケーションが仕事を遂行るには何が必要か」を問いかけるべき（ユーザがハッピーか？）
- DBとのやり取りがあるなら、DBの接続が有効で応答するか？
- 他のServiceに依存するなら、必要なServiceが利用できるかをチェック
- Readinessのチェック失敗は「自分は問題ないが、今はユーザのリクエストを処できない」となる
- つまりReadinessは、コンテナには何の問題もないが、依存関係にある要素のこかで障害が起こっているときに生きてくる
- マイクロサービスの最終チェーンが障害を起こしたとして、初めは最後から2番のチェーンがReadinessProbeに失敗 -> それを受けて最後から3番目が失敗 ->... -> 一番最初のチェーンがReadinessに失敗しブラックボックステストでアート＝これがサーキットブレイカーパターン
- そもそもサービスを設計する際には、コンポーネントとなっているサービスの1つ上が利用できなくなったとして場合でもシステム障害となることは避けるべき
- つまり優雅に劣化する
- より高度なReadinessProbeとするなら、「このアプリケーションが仕事を遂行るには何が必要か」を問いかけるべき（ユーザがハッピーか？）
Kubernetesにおけるメトリクス
- メトリクスはすべて数値であるため、ログと違い計算や統計を行うことができる
- メトリクス値は大きく2つのタイプに分かれる
- カウンタ：増えていく（または0にリセットする）ことしかできず、リクエストの数捕捉したエラーの数の測定に優れている
- ゲージ：増減ともに可能で、CPU使用率のように継続的に変化する量や他の数量との率を表すのに便利
- REDパターン
- USEパターン
- ビジネスメトリクス
- 例えば…
- ファネル分析（「ランディングページ閲覧人数」や「サインアップページへクリクスルーした人」）
- 顧客あたりの収益
- ログデータで集計するよりも、アプリケーションから時系列メトリクスを取得するこで可視化するほうが簡単
- 例えば…
- Kubernetesでのメトリクス収集
- クラスタの健全性に関するメトリクス
- ノードの数
- ノードの健全性ステータス
- ノードあたり、および全体のPodの数
- ノードあたり、および全体のリソース使用量/割当て
- Deploymentに関するメトリクス
- Deploymentの数
- Deploymentごとのレプリカの設定数
- Deploymentごとの利用できないレプリカの数
- コンテナに関するメトリクス
- ノードあたり、および全体のコンテナ/Podの数
- リソース要求/リソース制限に対する各コンテナのリソース使用率
- コンテナのLiveness/Readinessの状況
- コンテナ/Podの再起動回数
- 各コンテナのネットワーク入出力トラフィックおよびエラー
- ランタイムに関するメトリクス
- ヒープとスタックの使用量
- GC機能の実行時間など
- 非ヒープメモリの使用率
- クラスタの健全性に関するメトリクス
- 単純な平均の問題点
- 単純平均はハズレ値の影響を受けやすい
- 中央値の方が影響を受けにくく有用といえる
- 最悪のケースの方に関心がある場合が多いので、90%タイルがより有用なケースも
- どのサービスにおいてもダッシュボードのレイアウトは同じにしておく
- マスタダッシュボードで情報ラジエータを使用するのが理想的
- 重要なObservabilityデータを表示して関連するチームやオフィスの全員からみれようにする
感想
買ってよかった！
既知の内容少なかったし、監視周りはSRE本とそこから派生したブログ記事、入門監視あたりのエッセンスを集めてギュッとした感じがあって分かりやすかった。
仕事でも活かせやすい内容が多かったように思えます。