“K8S Ecology Weekly” mainly contains some recommended weekly information related to K8S ecology that I have come into contact with. Welcome to subscribe zhihu column “K8S Ecology”.

KIND v0.12.0 release

KIND (Kubernetes In Docker) is an open source project THAT I like very much and have been participating In. I’ve covered it many times in my previous articles for reference. I use it almost every day. It’s very convenient.

It’s been nearly 10 months since the last major release, V0.11, so let’s take a look at some of the notable features of this new release:

Currently, v0.12.0 uses Kubernetes v1.23.4 by default. If you upgrade KIND, the latest image will be pulled again. The image will be hosted on Docker Hub, which may be time-consuming. It is recommended to ensure smooth network.

Support for multiple architectures was specifically optimized in V0.12.0, and all published images by default include AMD64 and ARM64 support. All related components have been updated in the image:

  • Containerd v1.5.10
  • Crictl 1.23.0
  • The CNI plugin v1.1.0

Also fixed Docker + cgroup2 + rootless support, and WSL2 support. I recommend you upgrade.

Refer to its ReleaseNote for more details

Docker v20.10.13 release

Docker released v20.10.13 this week. Yes, you read that right, the current release is still patching v20.10. In fact, the latest code in the current Docker repository has many more features than V20.10, but it has not yet reached the goal of releasing a new large version, so it has not released a new large version.

Bugfixes and packaging-related changes are the main ones in this release. These include:

  • Upgrade Buildx to v0.8.0.
  • # 43165Fixed when usedlocalIf a large number of logs are generated in the log-driven mode, OOM problems may occur.If any are in uselocalYou are advised to upgrade log-driven partners
  • # 43147Fixed Fluentd log driver coordinationfluentd-async-connect=trueWhen the remote service is unavailable, the Docker Daemon may crash.
  • Do not compile in image manifests, do not compile in mmmanifests, do not compile in MMmanifests

Therefore, if you use local or Fluentd log drivers, please try to upgrade Docker. Other scenarios can be judged by yourself.

Refer to its ReleaseNote for more details

Helm v3.8 release

Helm V3.8 is a feature release in which the biggest change is the move to GA support for OCI Registry.

If you want to login to an OCI registry, you can use the helm registry login image repository using a usage similar to the Docker CLI.

For example, you can run the following command to log in to the GitHub mirror repository address:

➜ (MoeLove) ~ helm Registry login ghcr. IO Username: tao12345666333 Password: login SucceededCopy the code

It actually refers to the practice of the Docker CLI, including the configuration file structure and so on are consistent with the Docker CLI.

If you want to submit Helm Chart to the GitHub mirror repository, you can do the following:

(MoeLove) ➜ helm Create foo Creating foo (MoeLove) ➜ helm Package foo Successfully packaged chart and saved it to: / TMP/foo - 0.1.0 from TGZ (MoeLove) ➜ helm push foo - 0.1.0 from. TGZ oci: / / GHCR. IO/tao12345666333 / foo - chart Pushed: GHCR. IO/tao12345666333 / foo - chart/foo: 0.1.0 from Digest: sha256:1b0a889b4e0fee5b5679512182fc6c2e802f39bdc5ba9d11fff0affb962b9b49Copy the code

You can also use the following command to complete the pull operation of Chart:

# Pull chart (MoeLove) ➜ helm Pull oci: / / GHCR. IO/tao12345666333 / foo - chart/foo -- version 0.1.0 from Pulled: GHCR. IO/tao12345666333 / foo - chart/foo: 0.1.0 from Digest: sha256:1b0a889b4e0fee5b5679512182fc6c2e802f39bdc5ba9d11fff0affb962b9b49Copy the code

Or installation operation:

# the Install (MoeLove) ➜ helm Install foo oci: / / GHCR. IO/tao12345666333 / foo - chart/foo -- version 0.1.0 from NAME: foo LAST DEPLOYED: Sun Mar 13 16:52:55 2022 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: 1. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=foo,app.kubernetes.io/instance=foo" -o  jsonpath="{.items[0].metadata.name}") export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o Jsonpath ="{.spec.containers[0].ports[0].containerPort}") echo "Visit http://127.0.0.1:8080 to use your application" kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORTCopy the code

The biggest benefit of OCI support to GA this time is that we no longer need to maintain the container image repository and Helm Chart’s repository separately. Can directly use the same, maintenance costs can be reduced.

Progress in the upstream

This is kep-2799: The Reduction of Secret-based Service Account Tokens is mainly due to the default Kubernetes Service Account Token mechanism. If a Pod references a Service Account, the corresponding Token is mounted for it by default. Of course, we can also through configuration automountServiceAccountToken: false to avoid this behavior.

In this PR, sets the LegacyServiceAccountTokenNoAutoGeneration characteristics to beta level, and in Kubernetes v1.24 version will be enabled by default. By default, all newly created ServiceAccounts do not obtain the Token information. This is an extra note, of course, and this change does not affect Pod usage.

Other changes

  • Thanos v0.25 release
  • Knative v1.3 release
  • CNI plugins v1.1.0 was released

Please feel free to subscribe to my official account [MoeLove]