前提

「つくって、壊して、直して学ぶ Kubernetes入門」を読んだまとめです。書籍に記載のHands-Onはまだしてないけど、絵柄がかわいいし概要めちゃくちゃつかみやすくてよいです。
なお、昔ながらのインフラは何となく雰囲気でわかるものの今風なやつは全然わからず読んでみました。あとQiita初心者です

得た知識

Kubernetesとは、Dockerとかのコンテナを便利に管理するツール
コンテナを束ねてPodとして最小構成を作れる。主機能に加えて付随機能 (Log Archive機能など)を束ねるイメージ。ちなみにサブのやつはサイドカーと呼んだりする。この辺をマニフェストというレシピみたいなyamlファイル用意して管理していく
Podは通常直接デプロイせずReplicaSet/Deploymentという形でデプロイする。ReplicaSetは要するに冗長化で、Deploymentでバージョン管理をしている。Deploymentとしてリリースすることで無停止切替が可能(RecreateとRollingUpdateを選択可)
Deploymentだと負荷分散がないのでServiceというマニフェストを準備する。これ使うとクラスタIP用意したり外部のLBと紐づけができる
コンテナデプロイしてもリソースが不足してたり依存する他Serviceが立ち上がっていなかったりするケースがありトラブルは起こるものなので、Readiness probeなどを使ってヘルスチェックが必要
CPUとかメモリを指定してデプロイできる(必須・上限・QoSも設定可能)。SelectorといってSSDのノードだけにデプロイするとか、Affinityで近隣配置みたいなこともできる。Anti-Affinityでは同一ノードに載せないとか設定できるが、ノード以上にPodを増やせなくなるので、Pod Topology Spread Constraintsを使うとよい
ConfigMap/Secretを使うことで環境変数みたいなやつを管理できる。Secretであればアクセス権限の追加が可能
ProdとSTGで、マニフェストの差異が増えてくると管理が大変になるのでGitOpsの考え方を導入していく。Kustomizeを使えば、ベースのマニフェストに上書き(overlays)する形で環境固有の設定を管理できる
Kubernetesのアーキテクチャ上、コントロールプレーンとデータノードが分かれており、コントロールプレーンのプロセスがダウンしていてもデータノードは生き残っておりサービス継続が可能とのこと。その意味では障害に強いらしい

疑問/できていないこと

結局物理ノードを管理しようとしたときにどうやってやるのか全然わからなかったのでどうやるんだろ
一般的に適用するべき組織体制の在り方。DevOps的にAppの範囲は広がってくるのは明確に分かるが、インフラポジションはPlatform Eng.とかでいるはず。どういう体制ででかいシステム群を運用するんだろ
軸はちょっと違うがコンテナのセキュリティってどうするんだ。脆弱性管理とかパッチ適用とか

気づき・所感

マイクロサービスを突き進んできたとき、k8s (もしくはCloud Nativeサービス)は必須になるわなと感じた。
一方で周辺知識がめちゃくちゃ必要。マイクロサービスを選択するときのトレードオフなんだろうけど、普通に障害ポイントが増えているのと調査がめんどくさそう、可観測性は必須。あとリソース設定しやすいからこそのミスもあると思うので、GitOpsも必須。それだけデプロイ頻度高めていきたい会社のツールなんだろうという感想。
この辺考えると、Kubernetes真面目に運用するよりも、あたりまえだけどFargateとかApp ServiceとかのPaaSサービスうまく使ってシステム作ったほうが基本的には楽そう。あんま使ったことないけど
あと結局全部RESTになるわけでコンピューティングのリソース消費激しい気がする。