+
+ Nimm an einen kostenlosen Kurs bei edX teil
+
+
+
+
+
+ Einführung in Kubernetes
+
+ Möchtest Du Kubernetes lernen? Erfahre alles über dieses leistungsstarke System zur Verwaltung von Containeranwendungen.
+
+ Zum Kurs
+
+
+
+
+
+ Einführung in Cloud-Infrastruktur Technologien
+
+ Lerne die Grundlagen für den Aufbau und die Verwaltung von Cloud-Technologien direkt von der Linux Foundation, dem Marktführer im Bereich Open Source.
+
+ Zum Kurs
+
+
+
+
+
+ Einführung in Linux
+
+ Du hast nie Linux gelernt? Willst du eine Auffrischung? Erarbeite dir gute Linux-Kenntnisse über die grafische Oberfläche und die Kommandozeile der wichtigsten Linux-Distributionen.
+
+ Zum Kurs
+
+
+
+
+
+
+
+
+ Mit der Linux Foundation lernen
+ Die Linux Foundation bietet Kurse für alle Aspekte der Entwicklung und des Betriebs von Kubernetes-Anwendungen an, die entweder von Lehrkräften geleitet werden oder zum Selbststudium geeignet sind.
+
+ Kurse anzeigen
+
+
+
+
+
+
+
Werde Kubernetes zertifiziert
+
+
+
+ Kubernetes and Cloud Native Associate (KCNA)
+
+
Die Prüfung zum Kubernetes and Cloud Native Associate (KCNA) weist die grundlegenden Kenntnisse und Fähigkeiten eines Benutzers in Kubernetes und dem breiteren Cloud Native-Ökosystem nach.
+
Ein zertifizierter KCNA bestätigt konzeptionelles Wissen über das gesamte Cloud Native Ecosystem, mit besonderem Fokus auf Kubernetes.
+
+
Zur Zertifizierung
+
+
+
+ Certified Kubernetes Application Developer (CKAD)
+
+
Die Prüfung zum Certified Kubernetes Application Developer (Zertifizierter Kubernetes-Anwendungsentwickler) bescheinigt, dass Teilnehmer Cloud Native-Anwendungen für Kubernetes entwerfen, erstellen, konfigurieren und bereitstellen können.
+
Ein CKAD kann Anwendungsressourcen definieren und zentrale Elemente verwenden, um skalierbare Anwendungen und Tools in Kubernetes zu erstellen, zu überwachen und Fehler zu beheben.
+
+
Zur Zertifizierung
+
+
+
+ Certified Kubernetes Administrator (CKA)
+
+
Das Certified Kubernetes Administrator (CKA)-Programm garantiert, dass CKAs die Fähigkeiten, das Wissen und die Kompetenz besitzen, um die Aufgaben eines Kubernetes-Administrators zu erfüllen.
+
Ein zertifizierter Kubernetes-Administrator hat nachgewiesen, dass er in der Lage ist, grundlegende Installationen durchzuführen sowie Kubernetes-Cluster in einer Produktionsumgebung zu konfigurieren und zu verwalten.
+
+
Zur Zertifizierung
+
+
+
+ Certified Kubernetes Security Specialist (CKS)
+
+
Das Programm Certified Kubernetes Security Specialist (CKS) bietet die Gewissheit, dass der Zertifikatsinhaber mit einem breiten Spektrum an Best Practices vertraut ist und diese beherrscht. Die CKS-Zertifizierung umfasst Fähigkeiten zur Sicherung von Container-basierten Anwendungen und Kubernetes-Plattformen während der Erstellung, Bereitstellung und Laufzeit.
+
Kandidaten für den CKS müssen über eine aktuelle Zertifizierung als Certified Kubernetes Administrator (CKA) verfügen, um nachzuweisen, dass sie über ausreichende Kubernetes-Kenntnisse verfügen, bevor sie sich für den CKS anmelden.
+
+
Zur Zertifizierung
+
+
+
+
+
+
+
+ Kubernetes Schulungspartner
+ Unser Netzwerk von Kubernetes-Schulungspartnern bietet Schulungsangebote für Kubernetes- und Cloud Native-Projekte.
+
+
+
+ {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
+
+
diff --git a/content/en/blog/_posts/2020-10-12-steering-committee-results.md b/content/en/blog/_posts/2020-10-12-steering-committee-results.md
index 2acbb6d6e4..b47d9674f3 100644
--- a/content/en/blog/_posts/2020-10-12-steering-committee-results.md
+++ b/content/en/blog/_posts/2020-10-12-steering-committee-results.md
@@ -29,7 +29,7 @@ They join continuing members Christoph Blecker ([@cblecker](https://github.com/c
* Josh Berkus ([@jberkus](https://github.com/jberkus)), Red Hat
* Thanks to the Emeritus Steering Committee Members. Your prior service is appreciated by the community:
* Aaron Crickenberger ([@spiffxp](https://github.com/spiffxp)), Google
- * and Lachlan Evenson([@lachie8e)](https://github.com/lachie8e)), Microsoft
+ * and Lachlan Evenson([@lachie83)](https://github.com/lachie83)), Microsoft
* And thank you to all the candidates who came forward to run for election. As [Jorge Castro put it](https://twitter.com/castrojo/status/1315718627639820288?s=20): we are spoiled with capable, kind, and selfless volunteers who put the needs of the project first.
## Get Involved with the Steering Committee
diff --git a/content/en/blog/_posts/2021-08-06-server-side-apply-ga.md b/content/en/blog/_posts/2021-08-06-server-side-apply-ga.md
index eca57a561e..01403715cc 100644
--- a/content/en/blog/_posts/2021-08-06-server-side-apply-ga.md
+++ b/content/en/blog/_posts/2021-08-06-server-side-apply-ga.md
@@ -121,7 +121,7 @@ deploymentApplyConfig.Spec.Template.Spec.WithContainers(corev1ac.Container().
)
// apply
-applied, err := deploymentClient.Apply(ctx, extractedDeployment, metav1.ApplyOptions{FieldManager: fieldMgr})
+applied, err := deploymentClient.Apply(ctx, deploymentApplyConfig, metav1.ApplyOptions{FieldManager: fieldMgr})
```
For developers using Custom Resource Definitions (CRDs), the Kubebuilder apply support will provide the same capabilities. Documentation will be included in the Kubebuilder book when available.
diff --git a/content/en/blog/_posts/2021-11-08-steering-committee-results-2021.md b/content/en/blog/_posts/2021-11-08-steering-committee-results-2021.md
new file mode 100644
index 0000000000..922824e390
--- /dev/null
+++ b/content/en/blog/_posts/2021-11-08-steering-committee-results-2021.md
@@ -0,0 +1,56 @@
+---
+layout: blog
+title: "Announcing the 2021 Steering Committee Election Results"
+date: 2021-11-08
+slug: steering-committee-results-2021
+---
+
+**Author**: Kaslin Fields
+
+The [2021 Steering Committee Election](https://github.com/kubernetes/community/tree/master/events/elections/2021) is now complete. The Kubernetes Steering Committee consists of 7 seats, 4 of which were up for election in 2021. Incoming committee members serve a term of 2 years, and all members are elected by the Kubernetes Community.
+
+This community body is significant since it oversees the governance of the entire Kubernetes project. With that great power comes great responsibility. You can learn more about the steering committee’s role in their [charter](https://github.com/kubernetes/steering/blob/master/charter.md).
+
+## Results
+
+Congratulations to the elected committee members whose two year terms begin immediately (listed in alphabetical order by GitHub handle):
+
+* **Christoph Blecker ([@cblecker](https://github.com/cblecker)), Red Hat**
+* **Stephen Augustus ([@justaugustus](https://github.com/justaugustus)), Cisco**
+* **Paris Pittman ([@parispittman](https://github.com/parispittman)), Apple**
+* **Tim Pepper ([@tpepper](https://github.com/tpepper)), VMware**
+
+They join continuing members:
+
+* **Davanum Srinivas ([@dims](https://github.com/dims)), VMware**
+* **Jordan Liggitt ([@liggitt](https://github.com/liggitt)), Google**
+* **Bob Killen ([@mrbobbytables](https://github.com/mrbobbytables)), Google**
+
+Paris Pittman and Christoph Blecker are returning Steering Committee Members.
+
+## Big Thanks
+
+Thank you and congratulations on a successful election to this round’s election officers:
+
+* Alison Dowdney, ([@alisondy](https://github.com/alisondy))
+* Noah Kantrowitz ([@coderanger](https://github.com/coderanger))
+* Josh Berkus ([@jberkus](https://github.com/jberkus))
+
+Special thanks to Arnaud Meukam ([@ameukam](https://github.com/ameukam)), k8s-infra liaison, who enabled our voting software on community-owned infrastructure.
+
+Thanks to the Emeritus Steering Committee Members. Your prior service is appreciated by the community:
+
+* Derek Carr ([@derekwaynecarr](https://github.com/derekwaynecarr))
+* Nikhita Raghunath ([@nikhita](https://github.com/nikhita))
+
+And thank you to all the candidates who came forward to run for election.
+
+## Get Involved with the Steering Committee
+
+This governing body, like all of Kubernetes, is open to all. You can follow along with Steering Committee [backlog items](https://github.com/kubernetes/steering/projects/1) and weigh in by filing an issue or creating a PR against their [repo](https://github.com/kubernetes/steering). They have an open meeting on [the first Monday at 9:30am PT of every month](https://github.com/kubernetes/steering) and regularly attend Meet Our Contributors. They can also be contacted at their public mailing list steering@kubernetes.io.
+
+You can see what the Steering Committee meetings are all about by watching past meetings on the [YouTube Playlist](https://www.youtube.com/playlist?list=PL69nYSiGNLP1yP1B_nd9-drjoxp0Q14qM).
+
+---
+
+_This post was written by the [Upstream Marketing Working Group](https://github.com/kubernetes/community/tree/master/communication/marketing-team#contributor-marketing). If you want to write stories about the Kubernetes community, learn more about us._
diff --git a/content/en/blog/_posts/2021-11-09-non-root-containers-and-devices.md b/content/en/blog/_posts/2021-11-09-non-root-containers-and-devices.md
new file mode 100644
index 0000000000..8fd5cc6ba1
--- /dev/null
+++ b/content/en/blog/_posts/2021-11-09-non-root-containers-and-devices.md
@@ -0,0 +1,238 @@
+---
+layout: blog
+title: 'Non-root Containers And Devices'
+date: 2021-11-09
+slug: non-root-containers-and-devices
+---
+
+**Author:** Mikko Ylinen (Intel)
+
+The user/group ID related security settings in Pod's `securityContext` trigger a problem when users want to
+deploy containers that use accelerator devices (via [Kubernetes Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)) on Linux. In this blog
+post I talk about the problem and describe the work done so far to address it. It's not meant to be a long story about getting the [k/k issue](https://github.com/kubernetes/kubernetes/issues/92211) fixed.
+
+Instead, this post aims to raise awareness of the issue and to highlight important device use-cases too. This is needed as Kubernetes works on new related features such as support for user namespaces.
+
+## Why non-root containers can't use devices and why it matters
+One of the key security principles for running containers in Kubernetes is the
+principle of least privilege. The Pod/container `securityContext` specifies the config
+options to set, e.g., Linux capabilities, MAC policies, and user/group ID values to achieve this.
+
+Furthermore, the cluster admins are supported with tools like [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) (deprecated) or
+[Pod Security Admission](/docs/concepts/security/pod-security-admission/) (alpha) to enforce the desired security settings for pods that are being deployed in
+the cluster. These settings could, for instance, require that containers must be `runAsNonRoot` or
+that they are forbidden from running with root's group ID in `runAsGroup` or `supplementalGroups`.
+
+In Kubernetes, the kubelet builds the list of [`Device`](https://pkg.go.dev/k8s.io/cri-api@v0.22.1/pkg/apis/runtime/v1#Device) resources to be made available to a container
+(based on inputs from the Device Plugins) and the list is included in the CreateContainer CRI message
+sent to the CRI container runtime. Each `Device` contains little information: host/container device
+paths and the desired devices cgroups permissions.
+
+The [OCI Runtime Spec for Linux Container Configuration](https://github.com/opencontainers/runtime-spec/blob/master/config-linux.md)
+expects that in addition to the devices cgroup fields, more detailed information about the devices
+must be provided:
+
+```yaml
+{
+ "type": "
",
+ "path": "",
+ "major": ,
+ "minor": ,
+ "fileMode": ,
+ "uid": ,
+ "gid":
+},
+```
+
+The CRI container runtimes (containerd, CRI-O) are responsible for obtaining this information
+from the host for each `Device`. By default, the runtimes copy the host device's user and group IDs:
+
+- `uid` (uint32, OPTIONAL) - id of device owner in the container namespace.
+- `gid` (uint32, OPTIONAL) - id of device group in the container namespace.
+
+Similarly, the runtimes prepare other mandatory `config.json` sections based on the CRI fields,
+including the ones defined in `securityContext`: `runAsUser`/`runAsGroup`, which become part of the POSIX
+platforms user structure via:
+
+- `uid` (int, REQUIRED) specifies the user ID in the container namespace.
+- `gid` (int, REQUIRED) specifies the group ID in the container namespace.
+- `additionalGids` (array of ints, OPTIONAL) specifies additional group IDs in the container namespace to be added to the process.
+
+However, the resulting `config.json` triggers a problem when trying to run containers with
+both devices added and with non-root uid/gid set via `runAsUser`/`runAsGroup`: the container user process
+has no permission to use the device even when its group id (gid, copied from host) was permissive to
+non-root groups. This is because the container user does not belong to that host group (e.g., via `additionalGids`).
+
+Being able to run applications that use devices as non-root user is normal and expected to work so that
+the security principles can be met. Therefore, several alternatives were considered to get the gap filled with what the PodSec/CRI/OCI supports today.
+
+## What was done to solve the issue?
+You might have noticed from the problem definition that it would at least be possible to workaround
+the problem by manually adding the device gid(s) to `supplementalGroups`, or in
+the case of just one device, set `runAsGroup` to the device's group id. However, this is problematic because the device gid(s) may have
+different values depending on the nodes' distro/version in the cluster. For example, with GPUs the following commands for different distros and versions return different gids:
+
+Fedora 33:
+```
+$ ls -l /dev/dri/
+total 0
+drwxr-xr-x. 2 root root 80 19.10. 10:21 by-path
+crw-rw----+ 1 root video 226, 0 19.10. 10:42 card0
+crw-rw-rw-. 1 root render 226, 128 19.10. 10:21 renderD128
+$ grep -e video -e render /etc/group
+video:x:39:
+render:x:997:
+```
+
+Ubuntu 20.04:
+```
+$ ls -l /dev/dri/
+total 0
+drwxr-xr-x 2 root root 80 19.10. 17:36 by-path
+crw-rw---- 1 root video 226, 0 19.10. 17:36 card0
+crw-rw---- 1 root render 226, 128 19.10. 17:36 renderD128
+$ grep -e video -e render /etc/group
+video:x:44:
+render:x:133:
+```
+
+Which number to choose in your `securityContext`? Also, what if the `runAsGroup`/`runAsUser` values cannot be hard-coded because
+they are automatically assigned during pod admission time via external security policies?
+
+Unlike volumes with `fsGroup`, the devices have no official notion of `deviceGroup`/`deviceUser` that the CRI runtimes (or kubelet)
+would be able to use. We considered using container annotations set by the device plugins (e.g., `io.kubernetes.cri.hostDeviceSupplementalGroup/`) to get custom OCI `config.json` uid/gid values.
+This would have required changes to all existing device plugins which was not ideal.
+
+Instead, a solution that is *seamless* to end-users without getting the device plugin vendors involved was preferred. The selected approach was
+to re-use `runAsUser` and `runAsGroup` values in `config.json` for devices:
+
+```yaml
+{
+ "type": "c",
+ "path": "/dev/foo",
+ "major": 123,
+ "minor": 4,
+ "fileMode": 438,
+ "uid": ,
+ "gid":
+},
+```
+
+With `runc` OCI runtime (in non-rootless mode), the device is created (`mknod(2)`) in
+the container namespace and the ownership is changed to `runAsUser`/`runAsGroup` using `chmod(2)`.
+
+{{< note >}}
+[Rootless mode](/docs/tasks/administer-cluster/kubelet-in-userns/) and devices is not supported.
+{{}}
+Having the ownership updated in the container namespace is justified as the user process is the only one accessing the device. Only `runAsUser`/`runAsGroup`
+are taken into account, and, e.g., the `USER` setting in the container is currently ignored.
+
+While it is likely that the "faulty" deployments (i.e., non-root `securityContext` + devices) do not exist, to be absolutely sure no
+deployments break, an opt-in config entry in both containerd and CRI-O to enable the new behavior was added. The following:
+
+`device_ownership_from_security_context (bool)`
+
+defaults to `false` and must be enabled to use the feature.
+
+## See non-root containers using devices after the fix
+To demonstrate the new behavior, let's use a Data Plane Development Kit (DPDK) application using hardware accelerators, Kubernetes CPU manager, and HugePages as an example. The cluster runs containerd with:
+
+```toml
+[plugins]
+ [plugins."io.containerd.grpc.v1.cri"]
+ device_ownership_from_security_context = true
+```
+
+or CRI-O with:
+
+```toml
+[crio.runtime]
+device_ownership_from_security_context = true
+```
+
+and the `Guaranteed` QoS Class Pod that runs DPDK's crypto-perf test utility with this YAML:
+
+```yaml
+...
+metadata:
+ name: qat-dpdk
+spec:
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 2000
+ fsGroup: 3000
+ containers:
+ - name: crypto-perf
+ image: intel/crypto-perf:devel
+ ...
+ resources:
+ requests:
+ cpu: "3"
+ memory: "128Mi"
+ qat.intel.com/generic: '4'
+ hugepages-2Mi: "128Mi"
+ limits:
+ cpu: "3"
+ memory: "128Mi"
+ qat.intel.com/generic: '4'
+ hugepages-2Mi: "128Mi"
+ ...
+```
+
+To verify the results, check the user and group ID that the container runs as:
+
+```
+$ kubectl exec -it qat-dpdk -c crypto-perf -- id
+```
+
+They are set to non-zero values as expected:
+
+```
+uid=1000 gid=2000 groups=2000,3000
+```
+
+Next, check the device node permissions (`qat.intel.com/generic` exposes `/dev/vfio/` devices) are accessible to `runAsUser`/`runAsGroup`:
+
+```
+$ kubectl exec -it qat-dpdk -c crypto-perf -- ls -la /dev/vfio
+total 0
+drwxr-xr-x 2 root root 140 Sep 7 10:55 .
+drwxr-xr-x 7 root root 380 Sep 7 10:55 ..
+crw------- 1 1000 2000 241, 0 Sep 7 10:55 58
+crw------- 1 1000 2000 241, 2 Sep 7 10:55 60
+crw------- 1 1000 2000 241, 10 Sep 7 10:55 68
+crw------- 1 1000 2000 241, 11 Sep 7 10:55 69
+crw-rw-rw- 1 1000 2000 10, 196 Sep 7 10:55 vfio
+```
+
+Finally, check the non-root container is also allowed to create HugePages:
+
+```
+$ kubectl exec -it qat-dpdk -c crypto-perf -- ls -la /dev/hugepages/
+```
+
+`fsGroup` gives a `runAsUser` writable HugePages emptyDir mountpoint:
+
+```
+total 0
+drwxrwsr-x 2 root 3000 0 Sep 7 10:55 .
+drwxr-xr-x 7 root root 380 Sep 7 10:55 ..
+```
+
+## Help us test it and provide feedback!
+The functionality described here is expected to help with cluster security and the configurability of device permissions. To allow
+non-root containers to use devices requires cluster admins to opt-in to the functionality by setting
+`device_ownership_from_security_context = true`. To make it a default setting, please test it and provide your feedback (via SIG-Node meetings or issues)!
+The flag is available in CRI-O v1.22 release and queued for containerd v1.6.
+
+More work is needed to get it *properly* supported. It is known to work with `runc` but it also needs to be made to function
+with other OCI runtimes too, where applicable. For instance, Kata Containers supports device passthrough and allows it to make devices
+available to containers in VM sandboxes too.
+
+Moreover, the additional challenge comes with support of user names and devices. This problem is still [open](https://github.com/kubernetes/enhancements/pull/2101)
+and requires more brainstorming.
+
+Finally, it needs to be understood whether `runAsUser`/`runAsGroup` are enough or if device specific settings similar to `fsGroups` are needed in PodSpec/CRI v2.
+
+## Thanks
+My thanks goes to Mike Brown (IBM, containerd), Peter Hunt (Redhat, CRI-O), and Alexander Kanevskiy (Intel) for providing all the feedback and good conversations.
diff --git a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md
new file mode 100644
index 0000000000..b372e7e7b4
--- /dev/null
+++ b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md
@@ -0,0 +1,59 @@
+---
+layout: blog
+title: "Dockershim removal is coming. Are you ready?"
+date: 2021-11-12
+slug: are-you-ready-for-dockershim-removal
+---
+
+**Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano.
+
+Last year we announced that Dockershim is being deprecated: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/).
+Our current plan is to remove dockershim from the Kubernetes codebase soon.
+We are looking for feedback from you whether you are ready for dockershim
+removal and to ensure that you are ready when the time comes.
+**Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8**.
+
+The dockershim component that enables Docker as a Kubernetes container runtime is
+being deprecated in favor of runtimes that directly use the [Container Runtime Interface](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)
+created for Kubernetes. Many Kubernetes users have migrated to
+other container runtimes without problems. However we see that dockershim is
+still very popular. You may see some public numbers in recent [Container Report](https://www.datadoghq.com/container-report/#8) from DataDog.
+Some Kubernetes hosting vendors just recently enabled other runtimes support
+(especially for Windows nodes). And we know that many third party tools vendors
+are still not ready: [migrating telemetry and security agents](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/#telemetry-and-security-agent-vendors).
+
+At this point, we believe that there is feature parity between Docker and the
+other runtimes. Many end-users have used our [migration guide](/docs/tasks/administer-cluster/migrating-from-dockershim/)
+and are running production workload using these different runtimes. The plan of
+record today is that dockershim will be removed in version 1.24, slated for
+release around April of next year. For those developing or running alpha and
+beta versions, dockershim will be removed in December at the beginning of the
+1.24 release development cycle.
+
+There is only one month left to give us feedback. We want you to tell us how
+ready you are.
+
+**We are collecting opinions through this survey: [https://forms.gle/svCJmhvTv78jGdSx8](https://forms.gle/svCJmhvTv78jGdSx8)**
+To better understand preparedness for the dockershim removal, our survey is
+asking the version of Kubernetes you are currently using, and an estimate of
+when you think you will adopt Kubernetes 1.24. All the aggregated information
+on dockershim removal readiness will be published.
+Free form comments will be reviewed by SIG Node leadership. If you want to
+discuss any details of migrating from dockershim, report bugs or adoption
+blockers, you can use one of the SIG Node contact options any time:
+https://github.com/kubernetes/community/tree/master/sig-node#contact
+
+Kubernetes is a mature project. This deprecation is another
+step in the effort to get away from permanent beta features and providing more
+stability and compatibility guarantees. With the migration from dockershim you
+will get more flexibility and choice of container runtime features as well as
+less dependencies of your apps on specific underlying technology. Please take
+time to review the [dockershim migration documentation](/docs/tasks/administer-cluster/migrating-from-dockershim/)
+and consult your Kubernetes hosting vendor (if you have one) what container runtime options are available for you.
+Read up [container runtime documentation with instructions on how to use containerd and CRI-O](/docs/setup/production-environment/container-runtimes/#container-runtimes)
+to help prepare you when you're ready to upgrade to 1.24. CRI-O, containerd, and
+Docker with [Mirantis cri-dockerd](https://github.com/Mirantis/cri-dockerd) are
+not the only container runtime options, we encourage you to explore the [CNCF landscape on container runtimes](https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category)
+in case another suits you better.
+
+Thank you!
diff --git a/content/en/community/_index.html b/content/en/community/_index.html
index b41323c69e..c08aa25ae0 100644
--- a/content/en/community/_index.html
+++ b/content/en/community/_index.html
@@ -19,6 +19,7 @@ cid: community
+ 
+ 
+ 
+