Kubernetes 1.27版本中的SIG-CLI（kubectl）的变更内容

2 年 ago
新, 韵
6 minutes

这里总结了来自 Kubernetes 1.27 的 CHANGELOG 的 SIG-CLI (kubectl) 努力的内容。这是作者的评论。

    https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.27.md

新增的重要指令和标志

kubectl auth whoami コマンド: 自分自身の属性を確認する

kubectl debug –file/-f フラグ: デバッグするリソースの指定

主要命令和标记发生了变更。

kubectl explain –output フラグ: スキーマを表示する形式 (plaintext, plaintext-openapiv2) (デフォルト “plaintext”)

将被废弃的指令和标志

無【む】し

已删除的命令和标记

kubectl alpha auth whoami: コマンド: 自分自身の属性を確認する

kubectl kustomize –reorder フラグ: 出力する直前にリソースを並び替える

另外，您可以在此链接上查看详细的更改内容：https://github.com/superbrothers/kubectl-docs/compare/v1.26.0…v1.27.0。

感受

这个版本与 SIG-CLI 相关的变更特别少。

    • 自分自身の属性が確認できる kubectl auth whoami コマンドが昇格しましたが、このコマンドが使用する API がベータでデフォルトで無効のためまだ使用できません

kubectl debug コマンドにデバック目的に応じたプロファイルを指定する機能が追加されました。よさそうです

大规模功能升级中，有一个名为 ApplySet 的功能。这个功能是在 kubectl apply 命令的 –prune 功能基础上进行了革新，最初是作为 Alpha 版添加的。我记得很久以前为了找到一种方法来使用 prune 而苦苦挣扎的日子。虽然这个功能并不实用，但我们还是对 ApplySet 寄予了期望。通常情况下，GitOps 工具会自己实现类似 prune 的功能，因此直接使用并不是太方便的情况可能并不多。请看看我在页面末尾写下的使用感受。

有什么新变化（主要主题）

关于SIG-CLI没有相关信息。

紧急升级注意事项（必须先阅读后进行升级的事项）

没有与SIG-CLI相关的信息。

分类变更

Deprecation (廃止) – 废除

SIG-CLI 没有相关信息。

API 变更

SelfSubjectReview がベータに昇格しました (#116274, nabokihms) [SIG API Machinery, Auth, CLI and Testing] [sig/api-machinery,sig/auth,sig/cli,sig/testing]

SelfSubjectReview のベータ昇格に合わせて kubectl alpha auth whoami コマンドが kubectl auth whoami に昇格しています

SelfSubjectReviews API がデフォルトで有効になっていないため、使用するには明示的に API を有効にする必要があります。これはおそらく v1.24 から Beta API はデフォルト無効に変更されたためだと思われます。

Beta APIs Are Off by Default · Issue #3136 · kubernetes/enhancements

功能

kubectl debug に “general”, “baseline”, “restricted” のデバッグプロファイルが追加しました (#114280, sding3) [SIG CLI] [sig/cli]

kubectl debug をロンチしてからユーザから生成される Pod やコンテナでより設定を柔軟にできるようにしたいというフィードバックがあり、それを受けて追加された機能。事前に定義されたプロファイルを選択させるという方法を取ることで、有効にしたい機能を細かくフラグで指定させる煩雑な作業を避けられるようにしたとのこと。個々のプロファイルはデバッグ目的より使い分けることになっている。

general: 合理的なデフォルトのセット

baseline: Pod Security Standard の baseline と互換

restricted: Pod Security Standard の restricted と互換

legacy: 1.22 での挙動との後方互換

それそれのプロファイルで有効になる機能は、デバッグ対象が Node なのか、Pod Copy なのか Ephemeral Container なのかで異なり、正確なところは実装をみるしかないので分かりにくい気がする

https://github.com/kubernetes/kubernetes/blob/v1.27.0/staging/src/k8s.io/kubectl/pkg/cmd/debug/profiles.go#L126-L148

kubectl debug に netadmin デバッグプロファイルを追加しました (#115712, wedaly) [SIG CLI] [sig/cli]

これはネットワークデバッグのためのプロファイルで、NET_ADMIN Capability と Node が対象の場合は privileged, host namespace の使用が設定される

kubectl explain に古い openapiv2 の explain 実装を使う –output plaintext-openapiv2 引数が追加しました (#115480, alexzielenski) [sig/node,sig/auth,sig/cli,sig/architecture,sig/cloud-provider]

–output フラグのデフォルト値は plain で OpenAPIv3 を使います

ベータへの昇格のために kubectl –subresource に e2e テストを追加しました (#116590, MadhavJivrajani) [sig/cli,sig/testing]
debug コマンドに明示的な名前の代わりに pod または node のファイルを渡せる新しい -f フラグを追加しました (#111453, ardaguclu) [sig/cli,sig/testing]

-f/–file にマニフェストファイルを渡して kubectl debug コマンドを実行できるようになったという意味です

kubectl –subresource フラグがベータに変更されました (#116595, MadhavJivrajani) [sig/cli]
Kubectl は値があれば pods, containers, ephemeral containers で SeccompProfile を表示するようになりました (#113284, williamyeh) [sig/cli,sig/security]

表示するというのは kubectl describe コマンドでです
$ kubectl describe po nginx-655d4774bb-k7fnw | grep SeccompProfile
SeccompProfile: RuntimeDefault

Kubectl: default container annotation の e2e test を追加しました (#115046, pacoxu) [sig/cli,sig/testing,sig/architecture]

whoami kubectl コマンドを昇格 (#116510, nabokihms) [sig/auth,sig/cli]

kubectl alpha auth whoami コマンドは削除されました

Kubernetes v1.5 から kubectl apply にはアルファステージの –prune フラグがあり、以前適用されたオブジェクトが渡されたマニフェストから削除されている場合、そのオブジェクトを削除することをサポートしています。この機能は設計に元から存在するパフォーマンスと正確性の問題によりアルファにとどまり続けています。この PR は ApplySets という新しい標準によって実現された、第二の独立した pruning をアルファで公開します。ApplySet は server-side オブジェクト (デフォルトでは Secret, Configmaps も可) で、kubectl が apply 操作全体でセットメンバーシップを正確かつ効率的に追跡するための使用できます。ApplySet で使用される形式は、低レベルの仕様として KEP 3659 で規定されています。エコシステム内の他のツールも相互運用性を向上させるためにこの仕様に基づいて構築できます。ApplySet に基づくアルファの pruning を試すには KUBECTl_APPLYSET=true と –prune –applyset=secret-name というフラグを kubectl apply につけてください。 (#116205, justinsb) [sig/cli]

ApplySet 機能についてはページ最後にまとめています

kubectl explain はサーバが公開する OpenAPIV3 の情報を使うように変更されました (#116390, alexzielenski) [SIG API Machinery, CLI and Testing] [sig/api-machinery,sig/cli,sig/testing]

https://github.com/kubernetes-sigs/kustomize/pull/4954: gh: をホストとして使用するためのサポートを削除。これの使用方法と根拠を見出せず、カスタムの gitconfig の短縮構文を対象にしていたと考えられます

kubectl kustomize を kustomize v5.0.1 にアップグレードします。これは kustomize のメジャーリリースのため、いくつかの後方互換性のない変更が含まれますが、そのほとんどは稀なユースケース、副作用のあるバグ修正、またはすでにこれまでのリリースで非推奨とされているものです。 (#116598, natasha41575) [SIG CLI] [sig/cli]

Kustomize v5 の変更については Kubernetes Meetup Tokyo 56 で発表があったので詳細はそちらを参照: [k8sjp #56] Kustomize v5 を含む最新機能とテクニックの紹介 – Speaker Deck

後方互換性のない変更として次があげられている

https://github.com/kubernetes-sigs/kustomize/pull/4911: Drop support for a very old, legacy style of patches. patches used to be allowed to be used as an alias for patchesStrategicMerge in kustomize v3. You now have to use patchesStrategicMerge explicitly, or update to the new syntax supported by patches. See examples in the PR description of https://github.com/kubernetes-sigs/kustomize/pull/4911.

https://github.com/kubernetes-sigs/kustomize/issues/4731: Remove a potential build-time side-effect in ConfigMapGenerator and SecretGenerator, which loaded values from the local environment under some circumstances, breaking kustomize build’s side-effect-free promise. While this behavior was never intended, we deprecated it and are announcing it as a breaking change since it existed for a long time. See also the Eschewed Features documentation.

https://github.com/kubernetes-sigs/kustomize/pull/4985: If you previously included .git in an AWS or Azure URL, we will no longer automatically remove that suffix. You may need to add an extra / to replace the .git for the URL to properly resolve.

https://github.com/kubernetes-sigs/kustomize/pull/4954: Drop support for using gh: as a host (e.g. gh:kubernetes-sigs/kustomize). We were unable to find any usage of or basis for this and believe it may have been targeting a custom gitconfig shorthand syntax.

[alpha: kubectl apply –prune –applyset] 特定のカスタムリソース (CR) を “ApplySet” の親オブジェクトとして使用できるようになりました。特定の CR でこれを有効にするには、それを定義する CustomResourceDefinition (CRD) に applyset.kubernetes.io/is-parent-type: true ラベルを適用します。(#116353, KnVerey) [sig/cli]

GitOps ツールの Flux は独自の CR のステータスに管理するリソースのリストを持っているので、そこからの移行が想定された変更です

ApplySet 機能についてはページ最後にまとめています

kubectl はデフォルトで HorizontalPodAutoscaler v2 を使うようになりました (#114886, a7i) [sig/cli]

文档

    • この変更は下記 CLI コマンドに影響する: kubectl create rolebinding -h (#107124, ptux) [SIG CLI] [sig/cli]

kubectl create rolebinding のヘルプメッセージが改善されただけ

错误或回归

dry-run を付けた際に kubectl scale コマンドに (dry run)、(server dry run) のサフィックスを追加しました (#114252, ardaguclu) [sig/cli,sig/testing]
続く kubectl rollout restart コマンドが1秒以内に実行された場合の kubectl rollout restart のエラーメッセージを変更しました (#113040, ardaguclu) [sig/cli]

kubectl rollout restart コマンドは、kubectl.kubernetes.io/restartedAt annotation に RFC3339 形式で実行時間を値としてパッチすることでロールアウトをトリガする仕組みとなっているが、RFC3339 は秒単位までしか扱っていないため、1秒以内に連続して kubectl rollout restart コマンドを実行しても二度目の実行は同じ値でパッチすることになり、「変更なし」として無視されてしまう。人間は通常1秒以内に連続して実行することがないので問題がないが、自動化のためのスクリプトでは起きる可能性がある。この修正ではそれが修正されたわけではなく、エラーメッセージに次の文章を追加してトリガされなかったことに気づけるようにするというもの。

if restart has already been triggered within the past second, please wait before attempting to trigger another

kubectl exec に渡されたファイルに複数のリソースが含まれる場合、エラーメッセージを cannot exec into multiple objects at a time に変更しました (#114249, ardaguclu) [sig/cli,sig/testing]
kubectl: kubectl diff の pruning 時にリソースをフィルタするためのラベルセレクタの使用を有効にしました (#114863, danlenar) [sig/cli,sig/testing]

kubectl diff –prune を実行するのに -l (ラベルセレクタ) を指定していてとしても Prune の処理でラベルセレクタが渡っておらず無視されてしまっていたのを修正したというもの

deployments を describe したときに OldReplicaSets はまだ利用可能な replicasets だけでなく deployment が制御する全てを常に表示するようになりました (#113083, llorllale) [SIG CLI] [sig/cli]

其他（清理或碎块）

没有与SIG-CLI相关的信息。

Alpha: ApplySet 功能

Chinese paraphrase: Alpha：ApplySet 功能

使用kubectl apply命令进行Kubernetes资源的声明性管理时，不必要的资源删除是一个问题。即使从清单文件中删除了不再需要的资源并通过kubectl apply进行应用，集群中创建的资源也不会被删除。为解决这个问题，Kubernetes v1.5添加了–prune标志。该功能是自动从集群中删除以前应用的资源，前提是这些资源已从清单中删除。然而，该功能存在某些资源仅受支持或由于无法预测的行为而可能导致意外删除资源的问题。对于这个功能，更安全和优秀的实现是ApplySet。ArgoCD和Flux等GitOps工具已经具有类似功能，但迁移到这些工具也是目标之一。ApplySet功能在v1.27版本中以Alpha级别存在，使用时需要明确设置环境变量。基本上，应避免在生产中使用Alpha级别的功能。

利用 ApplySet 功能可以通过标准化的标签和注释来构建资源组。这样可以准确地识别属于组的资源。此外，只使用内建功能如标签等，无需安装额外的 CRD。

在这里，我们将应用一个 Deployment 和一个 Service。

$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.1", GitCommit:"4c9411232e10168d7b050c49a1b59f6df9d7ea4b", GitTreeState:"clean", BuildDate:"2023-04-14T13:21:19Z", GoVersion:"go1.20.3", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.1", GitCommit:"4c9411232e10168d7b050c49a1b59f6df9d7ea4b", GitTreeState:"clean", BuildDate:"2023-04-19T20:53:25Z", GoVersion:"go1.20.3", Compiler:"gc", Platform:"linux/amd64"}

$ KUBECTL_APPLYSET=true kubectl apply -f nginx.yaml --prune --applyset=applyset-nginx -n default
deployment.apps/nginx created
service/nginx created

我来确认一下已创建的对象。

$ kubectl get secret,deploy,service --show-labels
NAME                    TYPE     DATA   AGE   LABELS
secret/applyset-nginx   Opaque   0      26s   applyset.kubernetes.io/id=applyset-KJRZa9n3K5KqyLy4h8wiB2NM8RkbsMbZgRrYCrkBV_E-v1

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE   LABELS
deployment.apps/nginx   1/1     1            1           26s   app=nginx,applyset.kubernetes.io/part-of=applyset-KJRZa9n3K5KqyLy4h8wiB2NM8RkbsMbZgRrYCrkBV_E-v1

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE   LABELS
service/kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP    34m   component=apiserver,provider=kubernetes
service/nginx        ClusterIP   10.96.113.111   <none>        8080/TCP   26s   app=nginx,applyset.kubernetes.io/part-of=applyset-KJRZa9n3K5KqyLy4h8wiB2NM8RkbsMbZgRrYCrkBV_E-v1

applyset-nginx Secret的applyset.kubernetes.io/id=applyset-KJRZa9n3K5KqyLy4h8wiB2NM8RkbsMbZgRrYCrkBV_E-v1标签已被附加。Deployment和Service资源上附加了applyset.kubernetes.io/part-of=applyset-KJRZa9n3K5KqyLy4h8wiB2NM8RkbsMbZgRrYCrkBV_E-v1标签。根据名为applyset.kubernetes.io/part-of的标签，可以看出此次应用的Deployment和Service与父资源相关联。顺便提一下，ID的格式是base64(sha256(…))。

从清单文件中删除服务资源，然后重新应用以确认是否正确删除。

$ cp nginx.yaml{,.bak}
$ vim nginx.yaml
$ diff -u nginx.yaml.bak nginx.yaml
--- nginx.yaml.bak      2023-05-10 14:32:43.799310894 +0900
+++ nginx.yaml  2023-05-10 14:32:50.051398622 +0900
@@ -17,17 +17,3 @@
       containers:
       - image: nginxinc/nginx-unprivileged
         name: nginx-unprivileged
----
-apiVersion: v1
-kind: Service
-metadata:
-  labels:
-    app: nginx
-  name: nginx
-spec:
-  ports:
-  - port: 8080
-    protocol: TCP
-    targetPort: 8080
-  selector:
-    app: nginx

$ KUBECTL_APPLYSET=true kubectl apply -f nginx.yaml --prune --applyset=applyset-nginx -n default
deployment.apps/nginx unchanged
service/nginx pruned
$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   41m

通过service/nginx pruned 的消息，我们可以知道已经成功删除了。

虽然以上功能看起来很方便，但也存在一些问题。首先，不推荐使用ApplySet来管理跨多个命名空间的资源。基本上，应该在创建父资源的命名空间中将资源作为一个组进行管理。虽然规范中包含了跨多个命名空间或管理集群级别的资源的功能（尚未确认是否在v1.26中实施，至少似乎不能使用kubectl apply命令）。由于第三方提供的清单中可能包含CRD或者要求在kube-system命名空间中创建角色资源，所以在实际情况中很难将其限定在命名空间内。
此外，执行kubectl apply时需要明确指定父资源。要查找哪个是父资源并且必须逐个指定是很麻烦的。但通过重新审视用户体验，可以改善这一点，并且如果GitOps工具在内部使用，则可能不会成为问题。我认为在生产环境中使用某种GitOps工具，即使kubectl apply命令的ApplySet功能不够充分也不会有问题。

您可以在 ApplySet 的 Issue #3659，即 “kubectl apply –prune redesign and graduation strategy” 中查阅有关 ApplySet 功能的详细信息。

bannerAds