K8sメモメモ
kube-controller-manager
https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/
Node-ControllerとかReplication-Controllerとか、K8sデフォルトのhoge controllerはkube-controller-managerという一つのprocessに統合されている。
kindで建てたclusterだとkube-system namespaceにPodとして建っている。k8sのセットアップ方法によってはk8s外のprocessとして建っている場合もあるそう。
kubectl get pods -n kube-system | grep kube-controller-manager
kube-controller-manager-kind-control-plane 1/1 Running 0 22mkube-scheduler
https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/
Pod配置のためのschedulerもkind環境ではPodとして建っている。
kubectl get pods -n kube-system | grep kube-scheduler
kube-scheduler-kind-control-plane 1/1 Running 0 25mResourceQuota
https://kubernetes.io/docs/concepts/policy/resource-quotas/
namespaceごとのリソース要求量を制限できる。
https://kubernetes.io/docs/concepts/policy/resource-quotas/#enabling-resource-quota
kube-api-serverの起動オプションを見ると有効化されているかどうかがわかるらしい。
Static Pods
https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/
kubeletによって直接生成されるPod群。control planeノードの構築とかに一役買ってるケースが有るらしい。
この機能によってK8s外のシステムとしてはkublet(とcontainer runtime)があればK8sのセットアップが進むっていうわけか...感動した。
https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/
ownerReferencesフィールドを見てNodeが格納されていたらStatic Podとも言えそう。
PriorityClass
https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/
podのスケジューリングに優先度をつけることができる。リソースが足りないときは優先度の低いPodがevictされる。
PDBも見てはくれるけど、PriorityClassの優先度が高いPodのほうが優先されるらしい。
Deployment undo
新しいreplicasetに問題がある場合はkubectl rollout undoコマンドで以前のreplicasetに戻すことができる。
Max Unavailable & Max surge
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment
max unavailable: 古い方のreplicasetのscale downをどこまで許容するか。絶対値もしくは%で指定。切り上げ。
max surge: 新しいreplicasetのscale upをどこまで許容するか。絶対値もしくは%で指定。切り下げ。
どちらもdefaultは25%
Encrypting Confidential Data at Rest
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
etcd暗号化
kubeapi-server起動時に設定ファイルを引数として与えることで暗号化できる。暗号化手法も選択することができる。
kubectlコマンドのkubeapi serverとの通信を見る
$ kubectl --v=8 get pods--vオプションに渡す数字によって詳細度合いが変化する。debugには便利そう。ヘッダを見ることで自分がどの認証方法でkubeapi serverにアクセスしているのかもわかる。
kubectlでヘッダを出さずに結果を確認
リソースがいくつあるかとかをwcと組み合わせて見たいときとかに使える
$ kubectl get pods --no-headerskubectlでapi resourceを確認したいとき
Role作りたいときとかに便利かも。
$ kubectl api-resources
NAME SHORTNAMES APIVERSION NAMESPACED KIND
...
pods po v1 true Pod
...Dockerコンテナネットワーク
https://docs.docker.com/engine/network/drivers/
いろいろな種類がある。docker composeコマンドで親しんでいたのはbridgeだったのだなと理解。
docker composeごとに意識しなくても専用のbridgeが作成されていて、container間は疎通できるようになっていた。
CNI
https://github.com/containernetworking/cni
CNIはk8sからは独立しているんだ。(CNI自体をkubeletから呼び出していたりしたのかな？今はCRI寄りになっていたりする？細かい部分は追って学習)
このあたりを見てもそうなのかなという感じはする。
https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/
defaultで、CNI pluginは/opt/cni/bin配下に配置されていて、どのCNI pluginを有効化しているかは/etc/cni/net.d/10-flannel.conflistで確認できる。
cgroup driver
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/
kubeadmでクラスタを構築する際にcgroup driverが必須となる。関連するdocは↑の通り。
https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cgroup-drivers
そもそもの意義とかはこっちのほうがわかりやすい。cgroupfsとsystemdの２つのcgroup driverがあって、linux自体の起動がsystemdを介する場合やcgroup v2である場合はsystemd cgroup driverを使用するべきとのこと。最近はsystemd cgroup driverのほうが主流ってことになるのかな。
簡易的にはk8sを起動するマシンで
ps -p 1みたいな感じでsystemd経由で起動しているかどうかを調べられる。
Pod Priority and Preemption
https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: low-priority
value: -100
globalDefault: false
description: "This priority class should be used for low priority service pods only."valueが大きいほど優先してスケジューリングされる。
https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption
piorityClassが設定されているとPod間にpriorityの差が生じるようになり、highPriorityなPodがlowPriorityなPodをevictすることでスケジューリングできるようになるという状況になった場合はlowPriorityPodのevictionが起こるらしい。この挙動を変えるにはpreemptionPolicy: Neverを設定すると良い。
DNS for Services and Pods
https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
ServiceとPodのDNS解決ポリシーはこのページで確認できる。
Pod IP CIDR
ClusterレベルでPodに割り当てられるCluster IP CIDRと、NodeレベルでPodに割り当てられるNode IP CIDRが存在している。
Cluster IP CIDRの確認方法。kube-controller-managerの起動引数を確認する。
kubectl describe pod kube-controller-manager-<pod_name_suffix> -n kube-system
Command:
/usr/local/bin/kube-controller-manager
--cluster-cidr=10.244.0.0/16
--allocate-node-cidrs=trueもしくはclusterをkubeadmで構築している場合はkubeadmで参照したconfigmapからも確認することができる。
更に、allocate-node-cidrsの引数がtrueになっている場合はCluster IP CIDRのsubnetを各NodeのNode IP CIDRに割り当てている。
以下のように確認することができる。
kubectl describe node <node_name>
PodCIDR: 10.244.2.0/24CKA/CKAD用便利コマンド
あまり試験に特化したものを覚えてもしょうがないが...
namespace固定
kubectl config set-context --current --namespace=<namespace>resourceの一覧の確認。
kubectl api-resources
NAME SHORTNAMES APIVERSION NAMESPACED KIND
bindings v1 true Binding
componentstatuses cs v1 false ComponentStatus
configmaps cm v1 true ConfigMapresource定義の確認。階層を指定することで更に詳細を見ることができる。
kubectl explain csr
kubectl explain csr.spec