ry's Tech blog

Cloud Native技術などについて書いていきます。

Kubenews #19

2021-05-21

配信URL

youtu.be

各タイトルを押していただくことで、実際の記事に飛びます。

PromCon Online 2021 highlights

Introducing an Operator for Cortex

vcluster

kubenews #18

2021-05-14

配信URL

youtu.be

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
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”` をしてあげると、そのサービスのオーナーがすぐわかる。
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クラスターに直接アクセスできる必要があある。
    • 以下の様なツールを使って可視化しよう。

Using Finalizers to Control Deletion

  • kubectl delete
    • kubectl delete でリソースの状態は、live から collected になる。
  • 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 というステータスになる。
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

Kubenews #17

2021-04-30

配信URL

youtu.be

各タイトルを押していただくことで、実際の記事に飛びます。

Upcoming networking changes in Istio 1.10

Tracing in Grafana with Tempo and Jaeger

  • OpenTracingの基本的な要素
    • スパン:分散トレースの主要な構成要素で、名前、開始時間、および期間で構成される。
    • トレース:分散システムを通過するときの要求/トランザクションの視覚化。
    • タグ:スパンを識別するためのキー値情報で、トレースデータのクエリ、フィルタリング、分析に役立ちます。
    • ログ:ログは、スパン固有のログメッセージや、アプリケーション自体からのその他のデバッグまたは情報出力をキャプチャするのに役立つキーと値のペア。
    • スパンコンテキスト:特定のデータを着信要求に関連付けるプロセスであり、このコンテキストは、同じプロセス内のアプリケーションの他のすべてのレイヤーでアクセスが可能
  • OpenTracingと互換性のある利用可能なツール
    • zipkin
    • Jeager
    • Appadash
    • Grafana Tempo

Horizontal Pod Autoscaler in Kubernetes

Kubenews #14

2021-04-02

配信URL

youtu.be

Quark Container

RUST製のOCI Runtime - OCI compatible - Secure - High Performance

ゲストシステムコールを通じて、QuarkのKernelを使う。 Host Kernelを使う場合は、QkernelからQcall + Host systemcall もしくは IO-Uring

Modern continuous delivery on Kubernetes for developers

〇 CDの概念 - 宣言型 - 開発者は何を行う必要があるかを定義し、残りをCDツールに処理させる - スケーラブル - 既存のパイプラインまたは宣言的に定義されたプロジェクトに、新しいサービスを追加することの容易性やサービスのこれらのさまざまな構成を維持することに対する労力を考慮する必要がある。 - 拡張可能性 - 既存のツールを使用してCDワークフローと統合し、既存の機能とともに新しいカスタム機能を実装することができるか - Prometheusなどの可観測性ツールやJmeterやNeoloadなどのテスト自動化 - 品質ゲート - サービスを本番環境にデプロイする前に、具体的に定義された基準(応答時間、エラー率、スループットなど)が満たされていることを自動的に確認するための仕組み - SLI - 応答時間、エラー率、スループットなど、アプリケーションのいくつかの側面の定量的指標 - SLO - テストに合格するために満たす必要があるSLIを使用して特定の条件

〇 Keptonの紹介 - Kobaさん提供 - kubestrというツールについて

宣言型アプローチ

Keptnには、SLIやSLOなどのSRE原則に基づく組み込みの品質ゲートも含まれており、
定義された基準を評価およびスコアリングして、新しいバージョンを次の展開段階に昇格できるかどうか、
または保留する必要があるかどうかを判断できます。

JMeter、LitmusChaos、Prometheusなどの多くの有名なサービスとの統合をすでに備えており、ユーザーは独自の統合を簡単に追加できる。

この後、Keptonについての導入方法が書かれている。

Identify, Evaluate and Benchmark Kubernetes Storage

  • kobaさん提供
  • kubestrについて