kubenews #18
2021-05-14
配信URL
Kubernetes 変更内容共有会(v1.21)
- Youtube URL
- 自分的気になったポイント
- Allow DaemonSets to surge during update like Deployments
- DaemonSet に MaxSurge が導入
- CrossNamespacePodAffinity quota scope API
- namespaceSelectorやnamespaceフィールドを通して指定する、cross-namespaceなPodAffinityTermのNamespaceを制限します。(#98582)
- デフォルトのPodAffinityでは同じNamespaceに属するPodを考慮してスケジュール先を計算しますが、この機能を利用すると対象となるNamespaceを拡張できます。
- ProbeレベルのterminationGracePeriodSecondsフィールドを追加
- Generic Ephemeral Volumes
- Allow DaemonSets to surge during update like Deployments
volumes: - name: varlog hostPath: path: /var/log - name: scratch ephemeral: metadata: labels: type: fluentd-elasticsearch-volume
Annotating Kubernetes Services for Humans
- ヒューマンサービスディスカバリー
- サービス検出の人間的な側面
- 特定のサービスを所有しているのは誰ですか?チームはどのSlackチャネルに取り組んでいますか?サービスのソースはどこにありますか?現在知られ、追跡されている問題は何ですか?
- ここに対してはあまり注意が払われない。
- サービス検出の人間的な側面
- Kubernetesアノテーションは、この問題を正確に解決するように設計されている。
- 見積もりサービスと呼ばれる見積もり用のKubernetesサービスがあるとします。
- kubectl annotate service quote a8r.io/owner=”@sally”` をしてあげると、そのサービスのオーナーがすぐわかる。
- 見積もりサービスと呼ばれる見積もり用のKubernetesサービスがあるとします。
Name: quote Namespace: default Labels: <none> Annotations: a8r.io/owner: @sally Selector: app=quote Type: ClusterIP IP: 10.109.142.131 Port: http 80/TCP TargetPort: 8080/TCP Endpoints: <none> Session Affinity: None Events: <none>
- 注釈に共通の規則
- 注釈に共通の規則を採用することで、一貫性と理解性が保証される。
- サービスカタログ
- describeする上での問題
- マイクロサービスとアノテーションの数が急増するにつれて、実行kubectl describeは面倒になる可能性がある。
- さらに、を使用kubectl describeするには、すべての開発者がKubernetesクラスターに直接アクセスできる必要があある。
- 以下の様なツールを使って可視化しよう。
- describeする上での問題
Using Finalizers to Control Deletion
- kubectl delete
- kubectl delete でリソースの状態は、
live
からcollected
になる。
- kubectl delete でリソースの状態は、
- finalizer
- ファイナライザは、削除前の操作を通知するリソースのキー。
- リソースのガベージ コレクションを制御し、リソースを削除する前に実行するクリーンアップ操作をコントローラに警告するように設計されている。
- finalizerを含ませたリソースを作成して削除しようとすると、消えない。
- Kubernetes がオブジェクトにファイナライザーが含まれていることを確認し、読み取り専用の状態にしたから。
cat <<EOF | kubectl create -f - apiVersion: v1 kind: ConfigMap metadata: name: mymap finalizers: - kubernetes EOF
- finalizerを含むリソースに関しては、kubectl delete でリソースの状態は、
live
からfinalizaiton
になり、finalizer keyを取り除くことで、deletion
というステータスになる。
- finalizerを含むリソースに関しては、kubectl delete でリソースの状態は、
kubectl patch configmap/mymap \ --type json \ --patch='[ { "op": "remove", "path": "/metadata/finalizers" } ]'
- したがって、ファイナライザーを持つオブジェクトを削除しようとすると、コントローラがファイナライザーキーを削除するか、または Kubectl を使用してファイナライザーが削除されるまで、ファイナライズのままになります。ファイナライザーリストが空になると、オブジェクトは Kubernetes によって実際に再利用され、キューに入れ、レジストリから削除されます。
- 所有者
- 親オブジェクトを最初に作成し、次に子オブジェクトを作成すると、子を消しても親は消えないが、親を消すと子も消える。
cat <<EOF | kubectl create -f - apiVersion: v1 kind: ConfigMap metadata: name: mymap-parent EOF CM_UID=$(kubectl get configmap mymap-parent -o jsonpath="{.metadata.uid}") cat <<EOF | kubectl create -f - apiVersion: v1 kind: ConfigMap metadata: name: mymap-child ownerReferences: - apiVersion: v1 kind: ConfigMap name: mymap-parent uid: $CM_UID EOF
--cascade=false
を渡してあげると、親を消しても子は消えない。
kubectl delete --cascade=false configmap/mymap-parent configmap "mymap-parent" deleted kubectl get configmap NAME DATA AGE mymap-child 0 13m21s
- namespaceの強制終了
- namespaceを削除し、その下にあるすべてのオブジェクトを削除しても、その名前空間がまだ存在することがある。(Terminationの状態で残り続ける)
# kubectl get ns test-ns -o json > delete.json # vi delete.json { "apiVersion": "v1", "kind": "Namespace", "metadata": { "annotations": { ... "name": "test-ns", ... }, "spec": { "finalizers": [ "kubernetes" ] }, "status": { "phase": "Terminating" } }
- spec.finalizersを消して、APIに渡すと強制的に消せる。
# kubectl proxy & # curl -H "Content-Type: application/json" -X PUT --data-binary @delete.json http://127.0.0.1:8001/api/v1/namespaces/<ns>/finalize