2021-12-17

Where are my container's files? Inspecting container filesystems (click here to source)

Method 1: Exec into the container

コンテナのファイルシステムを調べる方法をいち早く知りたいのであれば、一般的な解決策はDockerコマンドを使用することである。

docker exec -it mycontainer /bin/bash

ただし、このアプローチの欠点の1つは、コンテナ内にシェルが存在する必要があることです。

コンテナ内に/bin/bash、 /bin/shまたは他のシェルが存在しない場合、このアプローチは機能しません

Method 2: Using nsenter

次のようなnsenterコマンドを使用して、ターゲットのコンテナがいる名前空間に入ることができます。

# Get the host PID of the process in the container
PID=$(docker container inspect mycontainer | jq '.[0].State.Pid')

# Use nsenter to go into the container’s mount namespace.
sudo nsenter -m -t $PID /bin/bash

これは、ターゲットであるプロセス(-t $PID)のmount (-m) namespaceに入り、/bin/bash を実行します。

このアプローチは、docker execアプローチよりも有望に見えるかもしれませんが、同様の/bin/bash問題が発生します。

ターゲットコンテナー内に（または他のシェルが）存在する必要があります。

Method 3: Copy with docker

上記の問題に対する別のアプローチは、関連するファイルをホストにコピーしてから、そのコピーを操作することです。

実行中のコンテナから選択したファイルをコピーするには、次を使用できます。

docker cp mycontainer:/path/to/file file

次の方法でファイルシステム全体のスナップショットを作成することもできます。

docker export mycontainer -o container_fs.tar

Method 4: Finding the filesystem on the host

ホストから直接コンテナのファイルシステムにアクセスしたいと思った際に、コンテナのファイルはホストのファイルシステムのどこかにあるはずですが、どこにあるのでしょうか？

Dockerのinspectコマンドには、次のような手がかりがあります。

docker container inspect mycontainer | jq '.[0].GraphDriver'

{
  "Data": {
    "LowerDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab-init/diff:/var/lib/docker/overlay2/524a0d000817a3c20c5d32b79c6153aea545ced8eed7b78ca25e0d74c97efc0d/diff",
    "MergedDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/merged",
    "UpperDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/diff",
    "WorkDir": "/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/work"
  },
  "Name": "overlay2"
}

LowerDir：最後のレイヤーを除く、コンテナー内のすべてのレイヤーのファイルシステムが含まれます
UpperDir：コンテナの最上位層のファイルシステム。これは、実行時の変更が反映される場所でもあります。
MergedDir：ファイルシステムのすべてのレイヤーを組み合わせたビュー。
WorkDir：ファイルシステムの管理に使用される内部作業ディレクトリ。

したがって、コンテナ内のファイルを確認するには、MergedDirパスを確認するだけです。

sudo ls /var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/merged

Method 5: /proc/[pid]/root

ホストからコンテナのファイルシステムを見つけるさらに簡単な方法があります。コンテナ内のプロセスのホストPIDを使用すると、次の操作を実行できます。

sudo ls / proc / [pid]/ root

Linuxは、プロセスのマウント名前空間を表示します。

Bonus: /proc/[pid]/mountinfo

方法4で説明したコンテナのオーバーレイファイルシステムに関するすべての情報は、Linux/procファイルシステムから直接検出することもできます。

/proc/<pid>/mountinfoを単に見ると、次のようなものが表示されます。

2363 1470 0:90 / / rw,relatime master:91 - overlay overlay rw,lowerdir=/var/lib/docker/overlay2/l/YZVAVZS6HYQHLGEPJHZSWTJ4ZU:/var/lib/docker/overlay2/l/ZYW5O24UWWKAUH6UW7K2DGV3PB,upperdir=/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/diff,workdir=/var/lib/docker/overlay2/63ec1a08b063c0226141a9071b5df7958880aae6be5dc9870a279a13ff7134ab/work
2364 2363 0:93 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
2365 2363 0:94 / /dev rw,nosuid - tmpfs tmpfs rw,size=65536k,mode=755,inode64
…

ここでは、コンテナがルートとしてオーバーレイファイルシステムをマウントしていることがわかります。

Horizontal Pod Autoscaling with Custom Metrics in Kubernetes (click here to source)

自動スケーリングに選択する最適なメトリックは、アプリケーションによって異なります。

コンテキストに応じて役立つ可能性のあるメトリックのリストは以下の通りです。

CPU
メモリー
リクエストスループット（HTTP、SQL、Kafka…）
平均、P90、またはP99リクエストのレイテンシ
ダウンストリーム依存関係のレイテンシ
アウトバウンド接続の数
特定の機能のレイテンシ
キューの深さ
保持されているロックの数

Kubernetesでの自動スケーリング

Kubernetesでの自動スケーリングデプロイのオプションについて詳しく説明しましょう。Kubernetesは、ポッドに対して2種類の自動スケーリングを提供します。

水平ポッド自動スケーリング（HPA）: 展開内のポッドの数を自動的に増減します。
垂直ポッド自動スケーリング（VPA）: デプロイメント内のポッドに割り当てられたリソースを自動的に増減します。

標準的なHPAのmanifestは以下の通り。

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-cpu-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

それに対し、カスタムメトリックを用いる場合以下のようになります。

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-custom-metric-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: my-custom-metric
      target:
        type: AverageValue
        averageUtilization: 20

metric[].pods.metric.nameでカスタムメトリック名を指定しているのがわかります。

Kubernetes Custom Metric API

Kubernetesがカスタムメトリックにアクセスするには、メトリックの提供を担当するカスタムメトリックサーバーを作成する必要があります。

フレームワークとして用意されたインターフェースを載せたGoサーバーを実装するだけで済みます。

type CustomMetricsProvider interface {
    // Fetches a single metric for a single resource.
    GetMetricByName(ctx context.Context, name types.NamespacedName, info CustomMetricInfo, metricSelector labels.Selector) (*custom_metrics.MetricValue, error)

    // Fetch all metrics matching the input selector, i.e. all pods in a particular namespace.
    GetMetricBySelector(ctx context.Context, namespace string, selector labels.Selector, info CustomMetricInfo, metricSelector labels.Selector) (*custom_metrics.MetricValueList, error)

    // List all available metrics.
    ListAllMetrics() []CustomMetricInfo
}

Prometheusなどは、Prometheus adapterというものが用意されていたりする。

qiita.com

How Krateo PlatformOps integrates Backstage (click here to source)

Krateo PlatformOps は、あらゆるタイプのリソースを一元的に作成および管理するための、包括的でモジュール式のアーキテクチャに基づくオープンソースプロジェクトです。

幅広いオープンソースプロジェクト（現在までに900以上）の中から最高の製品を選択するために、包括的なダッシュボードからそれらを管理し、一元的に調整可能なテンプレートを開発できる。

サービスカタログ的な感じかも。

以下がコンポーネントになる。

フロントエンドダッシュボード
- それはバックエンドに渡されるすべての要求されたフィールドを充填する形から開始する（コンポーネント名、説明、所有者、APIのURLなど）
バックエンドスペース
- 情報はテンプレートを埋めるために使用され、Gitのリポジトリに保存されます
Krateo Runtime (ArgoCD)
- ツールはGitリポジトリと同期し、マニフェストファイルに記述されているリソースの作成を処理します。
- gitリポジトリで行われたすべての変更は、リソースの変更を生成し、すべての変更の履歴を作成します。

kube-lineage: A CLI tool for visualizing Kubernetes object relationships (click here to source)

kube-lineageは、Kubernetesオブジェクトの関係を視覚化するためのCLIツールです。

krewプラグインマネージャーを使用して、kube-lineageをkubectlプラグインとしてインストールできます。

kubectl krew install lineage

実際の可視化は以下の通り。

$ kubectl lineage clusterrole/system:metrics-server
NAMESPACE     NAME                                                     READY   STATUS    AGE
              ClusterRole/system:metrics-server                        -                 5m
              └── ClusterRoleBinding/system:metrics-server             -                 5m
kube-system       └── ServiceAccount/metrics-server                    -                 5m
kube-system           ├── Pod/metrics-server-7b4f8b595-8m7rz           1/1     Running   5m
kube-system           │   └── Service/metrics-server                   -                 5m
                      │       ├── APIService/v1beta1.metrics.k8s.io    True              5m
kube-system           │       └── EndpointSlice/metrics-server-wb2cm   -                 5m
kube-system           └── Secret/metrics-server-token-nqw85            -                 5m
kube-system               └── Pod/metrics-server-7b4f8b595-8m7rz       1/1     Running   5m

helmにも対応をしているらしい。

$ RELEASE_NAME="kube-state-metrics"
$ kubectl lineage helm $RELEASE_NAME --depth=1
NAMESPACE    NAME                                                  READY   STATUS     AGE
monitoring   kube-state-metrics                                    True    Deployed   5m
             ├── ClusterRole/kube-state-metrics                    -                  5m
             ├── ClusterRoleBinding/kube-state-metrics             -                  5m
monitoring   ├── Deployment/kube-state-metrics                     1/1                5m
monitoring   ├── Secret/sh.helm.release.v1.kube-state-metrics.v1   -                  5m
monitoring   ├── Service/kube-state-metrics                        -                  5m
monitoring   └── ServiceAccount/kube-state-metrics                 -                  5m

How eBPF will solve Service Mesh - Goodbye Sidecars (click here to source)

勉強になりそうなので、載せました。

後日読もうと思います。

ry's Tech blog

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

Kubenews #41