Kubernetes メモメモ

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          22m

kube-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          25m

ResourceQuota

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

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-to-a-previous-revision

新しい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のログレベルとデバッグ

$ kubectl --v=8 get pods

--vオプションに渡す数字によって詳細度合いが変化する。debugには便利そう。ヘッダを見ることで自分がどの認証方法でkubeapi serverにアクセスしているのかもわかる。

kubectlでヘッダを出さずに結果を確認

リソースがいくつあるかとかをwcと組み合わせて見たいときとかに使える

$ kubectl get pods --no-headers

kubectlで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/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model

このあたりを見てもそうなのかなという感じはする。

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/24

Kubernetesのdefault Service

kube-api-server用に作成されているServiceにはselectorが存在していない。Endpointsのリソースを直接Serviceに対して作成している模様。

selector無しのServiceを使用するとPod以外のbackendも使用できるようになるとのこと。

Launch a Pod using service account token projection

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#launch-a-pod-using-service-account-token-projection

projected-volumesで、手動でPodの/var/run/secrets以下にservice account tokenを配置することができる。より詳細に制御することができるので、readOnlyやexpireSecondsの設定も可能。

Kubectl Nodeのuntaint

kubectl taint node controlplane node-role.kubernetes.io/control-plane:NoSchedule-
node/controlplane untainted

Pod ConditionsのContainersReadyとReadyの区別

https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions

ContainersReady: Podに含まれるすべてのコンテナがreadyな場合true

Ready: Podがリクエストを処理可能であり、Serviceのロードバランシングに含められる状態。

これら2つは一致しそうにも見えるが、例えば

- Pod終了時

- readinessGatesのカスタムreadinessが適用されている場合

には一致しなくなる。分けて考えるのが良さそう。

CKA/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         ConfigMap

resource定義の確認。階層を指定することで更に詳細を見ることができる。

kubectl explain csr
kubectl explain csr.spec
kubectl explain csr --recursive

kubeadmをaptで入れるとき

apt-cache madison kubeadm
   kubeadm | 1.34.3-1.1 | https://pkgs.k8s.io/core:/stable:/v1.34/deb  Packages
   kubeadm | 1.34.2-1.1 | https://pkgs.k8s.io/core:/stable:/v1.34/deb  Packages
   kubeadm | 1.34.1-1.1 | https://pkgs.k8s.io/core:/stable:/v1.34/deb  Packages
   kubeadm | 1.34.0-1.1 | https://pkgs.k8s.io/core:/stable:/v1.34/deb  Packages

versionをpinしてinstall

sudo apt-get install -y kubelet=1.34.0-1.1 kubeadm=1.34.0-1.1 kubect
l=1.34.0-1.1

kustomize buildしつつapply

kubectl apply -k .

kubeconfig全般で使用できるoptionの確認

kubectl options

--asのimpersonationや、--kubeconfigなどを確認する際に使用できる。