Merge pull request #31224 from nate-double-u/merged-main-dev-1.24

Merged main into dev 1.24

Author: k8s-ci-robot

CONTRIBUTING.md

@@ -34,6 +34,6 @@ Note that code issues should be filed against the main kubernetes repository, wh
 
 ### Submitting Documentation Pull Requests
 
-If you're fixing an issue in the existing documentation, you should submit a PR against the master branch.  Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/home/contribute/create-pull-request/).
+If you're fixing an issue in the existing documentation, you should submit a PR against the main branch.  Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/home/contribute/create-pull-request/).
 
 For more information, see [contributing to Kubernetes docs](https://kubernetes.io/docs/contribute/).

OWNERS_ALIASES

@@ -2,10 +2,12 @@ aliases:
   sig-docs-blog-owners: # Approvers for blog content
     - onlydole
     - mrbobbytables
+    - sftim
   sig-docs-blog-reviewers: # Reviewers for blog content
     - mrbobbytables
     - onlydole
     - sftim
+    - nate-double-u
   sig-docs-de-owners: # Admins for German content
     - bene2k1
     - mkorbi
@@ -125,6 +127,7 @@ aliases:
     - ClaudiaJKang
     - gochist
     - ianychoi
+    - jihoon-seo
     - seokho-son
     - ysyukr
   sig-docs-ko-reviews: # PR reviews for Korean content
@@ -242,19 +245,18 @@ aliases:
     - saschagrunert # SIG Chair
   release-engineering-approvers:
     - cpanato # Release Manager
-    - hasheddan # subproject owner / Release Manager
+    - palnabarun # Release Manager
     - puerco # Release Manager
     - saschagrunert # subproject owner / Release Manager
     - justaugustus # subproject owner / Release Manager
+    - Verolop # Release Manager
     - xmudrii # Release Manager
   release-engineering-reviewers:
     - ameukam # Release Manager Associate
     - jimangel # Release Manager Associate
     - markyjackson-taulia # Release Manager Associate
     - mkorbi # Release Manager Associate
-    - palnabarun # Release Manager Associate
     - onlydole # Release Manager Associate
     - sethmccombs # Release Manager Associate
     - thejoycekung # Release Manager Associate
-    - verolop # Release Manager Associate
     - wilsonehusin # Release Manager Associate

content/en/blog/_posts/2018-10-01-health-checking-grpc.md

@@ -4,10 +4,12 @@ title:  'Health checking gRPC servers on Kubernetes'
 date: 2018-10-01
 ---
 
-_Built-in gRPC probes were introduced in Kubernetes 1.23. To learn more, see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)._
-
 **Author**: [Ahmet Alp Balkan](https://twitter.com/ahmetb) (Google)
 
+**Update (December 2021):** _Kubernetes now has built-in gRPC health probes starting in v1.23.
+To learn more, see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe).
+This article was originally written about an external tool to achieve the same task._
+
 [gRPC](https://grpc.io) is on its way to becoming the lingua franca for
 communication between cloud-native microservices. If you are deploying gRPC
 applications to Kubernetes today, you may be wondering about the best way to

content/en/blog/_posts/2020-12-02-dockershim-faq.md

@@ -12,6 +12,8 @@ on the deprecation of Docker as a container runtime for Kubernetes kubelets, and
 what that means, check out the blog post
 [Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/).
 
+Also, you can read [check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) to check whether it does.
+
 ### Why is dockershim being deprecated?
 
 Maintaining dockershim has become a heavy burden on the Kubernetes maintainers.

content/en/blog/_posts/2021-12-09-pod-security-admission-beta.md

@@ -1,6 +1,6 @@
 ---
 layout: blog
-title: 'Pod Security Graduates to Beta'
+title: 'Kubernetes 1.23: Pod Security Graduates to Beta'
 date: 2021-12-09
 slug: pod-security-admission-beta
 ---

content/en/blog/_posts/2021-11-18-prevent-persistentvolume-leaks-when-deleting-out-of-order.md renamed to content/en/blog/_posts/2021-12-15-prevent-persistentvolume-leaks-when-deleting-out-of-order.md

@@ -1,6 +1,6 @@
 ---
 layout: blog
-title: "Kubernetes 1.23 Prevent PersistentVolume leaks when deleting out of order"
+title: "Kubernetes 1.23: Prevent PersistentVolume leaks when deleting out of order"
 date: 2021-12-15T10:00:00-08:00
 slug: kubernetes-1-23-prevent-persistentvolume-leaks-when-deleting-out-of-order
 ---

content/en/blog/_posts/2021-12-16-StatefulSet-PVC-Auto-Deletion.md

@@ -0,0 +1,103 @@
+---
+layout: blog
+title: 'Kubernetes 1.23: StatefulSet PVC Auto-Deletion (alpha)'
+date: 2021-12-16
+slug: kubernetes-1-23-statefulset-pvc-auto-deletion
+---
+
+**Author:** Matthew Cary (Google)
+
+Kubernetes v1.23 introduced a new, alpha-level policy for
+[StatefulSets](docs/concepts/workloads/controllers/statefulset/) that controls the lifetime of
+[PersistentVolumeClaims](docs/concepts/storage/persistent-volumes/) (PVCs) generated from the
+StatefulSet spec template for cases when they should be deleted automatically when the StatefulSet
+is deleted or pods in the StatefulSet are scaled down.
+
+## What problem does this solve?
+A StatefulSet spec can include Pod and PVC templates. When a replica is first created, the
+Kubernetes control plane creates a PVC for that replica if one does not already exist. The behavior
+before Kubernetes v1.23 was that the control plane never cleaned up the PVCs created for
+StatefulSets - this was left up to the cluster administrator, or to some add-on automation that
+you’d have to find, check suitability, and deploy. The common pattern for managing PVCs, either
+manually or through tools such as Helm, is that the PVCs are tracked by the tool that manages them,
+with explicit lifecycle. Workflows that use StatefulSets must determine on their own what PVCs are
+created by a StatefulSet and what their lifecycle should be.
+
+Before this new feature, when a StatefulSet-managed replica disappears, either because the
+StatefulSet is reducing its replica count, or because its StatefulSet is deleted, the PVC and its
+backing volume remains and must be manually deleted. While this behavior is appropriate when the
+data is critical, in many cases the persistent data in these PVCs is either temporary, or can be
+reconstructed from another source. In those cases, PVCs and their backing volumes remaining after
+their StatefulSet or replicas have been deleted are not necessary, incur cost, and require manual
+cleanup.
+
+## The new StatefulSet PVC retention policy
+
+If you enable the alpha feature, a StatefulSet spec includes a PersistentVolumeClaim retention
+policy.  This is used to control if and when PVCs created from a StatefulSet’s `volumeClaimTemplate`
+are deleted.  This first iteration of the retention policy contains two situations where PVCs may be
+deleted.
+
+The first situation is when the StatefulSet resource is deleted (which implies that all replicas are
+also deleted). This is controlled by the `whenDeleted` policy. The second situation, controlled by
+`whenScaled` is when the StatefulSet is scaled down, which removes some but not all of the replicas
+in a StatefulSet. In both cases the policy can either be `Retain`, where the corresponding PVCs are
+not touched, or `Delete`, which means that PVCs are deleted. The deletion is done with a normal
+[object deletion](/docs/concepts/architecture/garbage-collection/), so that, for example, all
+retention policies for the underlying PV are respected.
+
+This policy forms a matrix with four cases. I’ll walk through and give an example for each one.
+
+  * **`whenDeleted` and `whenScaled` are both `Retain`.** This matches the existing behavior for
+    StatefulSets, where no PVCs are deleted. This is also the default retention policy. It’s
+    appropriate to use when data on StatefulSet volumes may be irreplaceable and should only be
+    deleted manually.
+
+  * **`whenDeleted` is `Delete` and `whenScaled` is `Retain`.** In this case, PVCs are deleted only when
+    the entire StatefulSet is deleted. If the StatefulSet is scaled down, PVCs are not touched,
+    meaning they are available to be reattached if a scale-up occurs with any data from the previous
+    replica. This might be used for a temporary StatefulSet, such as in a CI instance or ETL
+    pipeline, where the data on the StatefulSet is needed only during the lifetime of the
+    StatefulSet lifetime, but while the task is running the data is not easily reconstructible. Any
+    retained state is needed for any replicas that scale down and then up.
+
+  * **`whenDeleted` and `whenScaled` are both `Delete`.** PVCs are deleted immediately when their
+    replica is no longer needed. Note this does not include when a Pod is deleted and a new version
+    rescheduled, for example when a node is drained and Pods need to migrate elsewhere. The PVC is
+    deleted only when the replica is no longer needed as signified by a scale-down or StatefulSet
+    deletion. This use case is for when data does not need to live beyond the life of its
+    replica. Perhaps the data is easily reconstructable and the cost savings of deleting unused PVCs
+    is more important than quick scale-up, or perhaps that when a new replica is created, any data
+    from a previous replica is not usable and must be reconstructed anyway.
+
+  * **`whenDeleted` is `Retain` and `whenScaled` is `Delete`.** This is similar to the previous case,
+    when there is little benefit to keeping PVCs for fast reuse during scale-up. An example of a
+    situation where you might use this is an Elasticsearch cluster. Typically you would scale that
+    workload up and down to match demand, whilst ensuring a minimum number of replicas (for example:
+    3). When scaling down, data is migrated away from removed replicas and there is no benefit to
+    retaining those PVCs. However, it can be useful to bring the entire Elasticsearch cluster down
+    temporarily for maintenance. If you need to take the Elasticsearch system offline, you can do
+    this by temporarily deleting the StatefulSet, and then bringing the Elasticsearch cluster back
+    by recreating the StatefulSet. The PVCs holding the Elasticsearch data will still exist and the
+    new replicas will automatically use them.
+
+Visit the
+[documentation](docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-policies) to
+see all the details.
+
+## What’s next?
+
+Enable the feature and try it out! Enable the `StatefulSetAutoDeletePVC` feature gate on a cluster,
+then create a StatefulSet using the new policy. Test it out and tell us what you think!
+
+I'm very curious to see if this owner reference mechanism works well in practice. For example, we
+realized there is no mechanism in Kubernetes for knowing who set a reference, so it’s possible that
+the StatefulSet controller may fight with custom controllers that set their own
+references. Fortunately, maintaining the existing retention behavior does not involve any new owner
+references, so default behavior will be compatible.
+
+Please tag any issues you report with the label `sig/apps` and assign them to Matthew Cary
+([@mattcary](https://github.com/mattcary) at GitHub).
+
+Enjoy!
+

content/en/blog/_posts/2021-12-17-security-profiles-operator-v0.4.0/index.md

@@ -0,0 +1,148 @@
+---
+layout: blog
+title: "What's new in Security Profiles Operator v0.4.0"
+date: 2021-12-17
+slug: security-profiles-operator
+---
+
+**Authors:** Jakub Hrozek, Juan Antonio Osorio, Paulo Gomes, Sascha Grunert
+
+---
+
+The [Security Profiles Operator (SPO)](https://sigs.k8s.io/security-profiles-operator)
+is an out-of-tree Kubernetes enhancement to make the management of
+[seccomp](https://en.wikipedia.org/wiki/Seccomp),
+[SELinux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) and
+[AppArmor](https://en.wikipedia.org/wiki/AppArmor) profiles easier and more
+convenient. We're happy to announce that we recently [released
+v0.4.0](https://github.com/kubernetes-sigs/security-profiles-operator/releases/tag/v0.4.0)
+of the operator, which contains a ton of new features, fixes and usability
+improvements.
+
+## What's new
+
+It has been a while since the last
+[v0.3.0](https://github.com/kubernetes-sigs/security-profiles-operator/releases/tag/v0.3.0)
+release of the operator. We added new features, fine-tuned existing ones and
+reworked our documentation in 290 commits over the past half year.
+
+One of the highlights is that we're now able to record seccomp and SELinux
+profiles using the operators [log enricher](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#log-enricher-based-recording).
+This allows us to reduce the dependencies required for profile recording to have
+[auditd](https://linux.die.net/man/8/auditd) or
+[syslog](https://en.wikipedia.org/wiki/Syslog) (as fallback) running on the
+nodes. All profile recordings in the operator work in the same way by using the
+`ProfileRecording` CRD as well as their corresponding [label
+selectors](/docs/concepts/overview/working-with-objects/labels). The log
+enricher itself can be also used to gather meaningful insights about seccomp and
+SELinux messages of a node. Checkout the [official
+documentation](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#using-the-log-enricher)
+to learn more about it.
+
+### seccomp related improvements
+
+Beside the log enricher based recording we now offer an alternative to record
+seccomp profiles by utilizing [ebpf](https://ebpf.io). This optional feature can
+be enabled by setting `enableBpfRecorder` to `true`. This results in running a
+dedicated container, which ships a custom bpf module on every node to collect
+the syscalls for containers. It even supports older Kernel versions which do not
+expose the [BPF Type Format (BTF)](https://www.kernel.org/doc/html/latest/bpf/btf.html) per
+default as well as the `amd64` and `arm64` architectures. Checkout
+[our documentation](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#ebpf-based-recording)
+to see it in action. By the way, we now add the seccomp profile architecture of
+the recorder host to the recorded profile as well.
+
+We also graduated the seccomp profile API from `v1alpha1` to `v1beta1`. This
+aligns with our overall goal to stabilize the CRD APIs over time. The only thing
+which has changed is that the seccomp profile type `Architectures` now points to
+`[]Arch` instead of `[]*Arch`.
+
+### SELinux enhancements
+
+Managing SELinux policies (an equivalent to using `semodule` that
+you would normally call on a single server) is not done by SPO
+itself, but by another container called selinuxd to provide better
+isolation. This release switched to using selinuxd containers from
+a personal repository to images located under [our team's quay.io
+repository](https://quay.io/organization/security-profiles-operator).
+The selinuxd repository has moved as well to [the containers GitHub
+organization](https://github.com/containers/selinuxd).
+
+Please note that selinuxd links dynamically to `libsemanage` and mounts the
+SELinux directories from the nodes, which means that the selinuxd container
+must be running the same distribution as the cluster nodes. SPO defaults
+to using CentOS-8 based containers, but we also build Fedora based ones.
+If you are using another distribution and would like us to add support for
+it, please file [an issue against selinuxd](https://github.com/containers/selinuxd/issues).
+
+#### Profile Recording
+
+This release adds support for recording of SELinux profiles.
+The recording itself is managed via an instance of a `ProfileRecording` Custom
+Resource as seen in an
+[example](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/profilerecording-selinux-logs.yaml)
+in our repository. From the user's point of view it works pretty much the same
+as recording of seccomp profiles.
+
+Under the hood, to know what the workload is doing SPO installs a special
+permissive policy called [selinuxrecording](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/deploy/base/profiles/selinuxrecording.cil)
+on startup which allows everything and logs all AVCs to `audit.log`.
+These AVC messages are scraped by the log enricher component and when
+the recorded workload exits, the policy is created.
+
+#### `SELinuxProfile` CRD graduation
+
+An `v1alpha2` version of the `SelinuxProfile` object has been introduced. This
+removes the raw Common Intermediate Language (CIL) from the object itself and
+instead adds a simple policy language to ease the writing and parsing
+experience.
+
+Alongside, a `RawSelinuxProfile` object was also introduced. This contains a
+wrapped and raw representation of the policy. This was intended for folks to be
+able to take their existing policies into use as soon as possible. However, on
+validations are done here.
+
+### AppArmor support
+
+This version introduces the initial support for AppArmor, allowing users to load and 
+unload AppArmor profiles into cluster nodes by using the new [AppArmorProfile](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/deploy/base/crds/apparmorprofile.yaml) CRD.
+
+To enable AppArmor support use the [enableAppArmor feature gate](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/config.yaml#L10) switch of your SPO configuration.
+Then use our [apparmor example](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/apparmorprofile.yaml) to deploy your first profile across your cluster.
+
+### Metrics
+
+The operator now exposes metrics, which are described in detail in
+our new [metrics documentation](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#using-metrics).
+We decided to secure the metrics retrieval process by using
+[kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy), while we ship an
+additional `spo-metrics-client` cluster role (and binding) to retrieve the
+metrics from within the cluster. If you're using
+[OpenShift](https://www.redhat.com/en/technologies/cloud-computing/openshift),
+then we provide an out of the box working
+[`ServiceMonitor`](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#automatic-servicemonitor-deployment)
+to access the metrics.
+
+#### Debuggability and robustness
+
+Beside all those new features, we decided to restructure parts of the Security
+Profiles Operator internally to make it better to debug and more robust. For
+example, we now maintain an internal [gRPC](https://grpc.io) API to communicate
+within the operator across different features. We also improved the performance
+of the log enricher, which now caches results for faster retrieval of the log
+data. The operator can be put into a more [verbose log mode](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#set-logging-verbosity)
+by setting `verbosity` from `0` to `1`.
+
+We also print the used `libseccomp` and `libbpf` versions on startup, as well as
+expose CPU and memory profiling endpoints for each container via the
+[`enableProfiling` option](https://github.com/kubernetes-sigs/security-profiles-operator/blob/71b3915/installation-usage.md#enable-cpu-and-memory-profiling).
+Dedicated liveness and startup probes inside of the operator daemon will now
+additionally improve the life cycle of the operator.
+
+## Conclusion
+
+Thank you for reading this update. We're looking forward to future enhancements
+of the operator and would love to get your feedback about the latest release.
+Feel free to reach out to us via the Kubernetes slack
+[#security-profiles-operator](https://kubernetes.slack.com/messages/security-profiles-operator)
+for any feedback or question.