SIG Node では、kubelet をベースに、(コンテナランタイムを通した)コンテナの制御や、ノード上のリソース管理に関するコンポーネントの開発を行っています。

Pod に基づいたコンテナの作成・削除、ボリュームのアタッチ、ログ管理など、その対象範囲は多岐にわたります。

1.33~1.34 までの主なアップデート

In-Place Pod Resize

Pod に割り当てる vCPU や、メモリの量を変えたい場合は、Pod 自体を再作成する必要がありましたが、Pod の再起動なしに割り当て変更を行う機能が、1.33 をもって beta に昇格しました。
(beta に昇格した機能は、デフォルトで有効になります)

In-Place Pod Resize では、 resize というサブリソースを操作することで、リソースの割り当てを変えることができます。

例えば、このような Pod があったとします。

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: default
spec:
  containers:
    - name: test-container
      image: nginx:latest
      ports:
        - containerPort: 80
  resources:
    limits:
      cpu: "100m"
      memory: "128Mi"
    requests:
      cpu: "50m"
      memory: "64Mi"

Describe してみます。

% kubectl describe pods test-pod
Name:             test-pod
*** 中略 ***
Containers:
  test-container:
    Limits:
      cpu:     100m
      memory:  128Mi
    Requests:
      cpu:        50m
      memory:     64Mi

kubectl を使い、 patch してみます。

% kubectl patch pod test-pod --subresource=resize -p '{"spec": {"containers": [{"name": "test-container", "resources": {"limits": {"cpu": "200Mi"}, "requests": {"cpu": "100Mi"}}}]}}'
pod/test-pod patched

Sidecar Container

私は、このセッションを聴くまで、サイドカーパターンといえば「 containers に2コンテナ目として入れる」で、「サイドカーコンテナはすでにあるじゃないか」と思っていたのですが、 initContainers に入れて、restartPolicy を Always にするというパターンができ、この度 GA に昇格しました。

例えば、WordPress コンテナに対して、サイドカーで CloudSQL Proxy のコンテナを持たせることをイメージすると、このようになります。

apiVersion: v1
kind: Pod
metadata:
  name: test-wordpress-pod
  namespace: default
spec:
  containers:
    - name: wordpress
      image: wordpress:latest
      ports:
        - containerPort: 80
      resources:
        limits:
          cpu: "200m"
          memory: "128Mi"
        requests:
          cpu: "100m"
          memory: "64Mi"
      env:
        - name: WORDPRESS_DB_HOST
          value: "localhost:3306"
  initContainers:
    - name: cloudsql-proxy
      image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:latest
      restartPolicy: Always
      args:
        - --credential_file=/secrets/cloudsql/credentials.json
        - <YOUR_CONNECTION_NAME>
      ports:
        - containerPort: 3306

apply してみると、コンテナが2つ稼働していることがわかります。

$ kubectl get pods
NAME                 READY   STATUS    RESTARTS   AGE
test-wordpress-pod   1/2     Running   0          13s

$ kubectl get pods
NAME                 READY   STATUS    RESTARTS   AGE
test-wordpress-pod   2/2     Running   0          33s

initContainers なので、コンテナの起動順序を明示することができ、上記のようにサイドカーで行う処理に依存する場合などの起動時処理が便利になりそうです。

KubeCon に参加してみて

KubeCon では、各社の事例紹介だけでなく、Kubernetes 自体のアップデートであったり、便利な OSS の紹介など、日々変化を続ける CloudNative の領域を鳥瞰することができました。

セッションのほとんどは英語で行われていたのもあり、英語が苦手な私にとっては、まだ理解が追いついていない部分はありますが、マルチクラスタ運用であったり、Pod のデバッグなど、私たちのプロジェクトの中でも共通する話題について、キーワードを持ち帰ることができました。

とりわけ印象的だったのは、(コミットに限らない)コントリビュートへの期待があちこちで見られたことです。
普段の業務では、OSS を利用しながらプラットフォームを作っていますが、OSS へのコントリビュートを通して、積極的にキャッチアップしていきたいと感じました。