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

Merged main into dev 1.24

Author: k8s-ci-robot

Dockerfile

@@ -4,29 +4,42 @@
 # change is that the Hugo version is now an overridable argument rather than a fixed
 # environment variable.
 
-FROM golang:1.15-alpine
+FROM golang:1.16-alpine
 
 LABEL maintainer="Luc Perkins <[email protected]>"
 
 RUN apk add --no-cache \
     curl \
+    gcc \
+    g++ \
+    musl-dev \
+    build-base \
+    libc6-compat
+
+ARG HUGO_VERSION
+
+RUN mkdir $HOME/src && \
+    cd $HOME/src && \
+    curl -L https://github.com/gohugoio/hugo/archive/refs/tags/v${HUGO_VERSION}.tar.gz | tar -xz && \
+    cd "hugo-${HUGO_VERSION}" && \
+    go install --tags extended
+
+FROM golang:1.16-alpine
+
+RUN apk add --no-cache \
     git \
     openssh-client \
     rsync \
-    build-base \
-    libc6-compat \
     npm && \
     npm install -D autoprefixer postcss-cli
 
-ARG HUGO_VERSION
-
 RUN mkdir -p /usr/local/src && \
     cd /usr/local/src && \
-    curl -L https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_Linux-64bit.tar.gz | tar -xz && \
-    mv hugo /usr/local/bin/hugo && \
     addgroup -Sg 1000 hugo && \
     adduser -Sg hugo -u 1000 -h /src hugo
 
+COPY --from=0 /go/bin/hugo /usr/local/bin/hugo
+
 WORKDIR /src
 
 USER hugo:hugo

OWNERS_ALIASES

@@ -31,6 +31,7 @@ aliases:
     - savitharaghunathan
     - sftim
     - tengqm
+    - zacharysarah
   sig-docs-en-reviews: # PR reviews for English content
     - bradtopol
     - celestehorgan
@@ -44,6 +45,7 @@ aliases:
     - sftim
     - shannonxtreme
     - tengqm
+    - zacharysarah
   sig-docs-es-owners: # Admins for Spanish content
     - raelga
     - electrocucaracha

README.md

@@ -167,6 +167,14 @@ For more information about contributing to the Kubernetes documentation, see:
 - [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
 - [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
 
+### New contributor ambassadors
+
+If you need help at any point when contributing, the [New Contributor Ambassadors](https://kubernetes.io/docs/contribute/advanced/#serve-as-a-new-contributor-ambassador) are a good point of contact. These are SIG Docs approvers whose responsibilities include mentoring new contributors and helping them through their first few pull requests. The best place to contact the New Contributors Ambassadors would be on the [Kubernetes Slack](https://slack.k8s.io/). Current New Contributors Ambassadors for SIG Docs:
+
+| Name                       | Slack                      | GitHub                     |                   
+| -------------------------- | -------------------------- | -------------------------- |
+| Arsh Sharma                | @arsh                      | @RinkiyaKeDad              |
+
 ## Localization `README.md`'s
 
 | Language                   | Language                   |

content/en/blog/_posts/2015-04-00-Faster-Than-Speeding-Latte.md

@@ -1,8 +1,11 @@
 ---
-title: " Faster than a speeding Latte "
+title: "Faster than a speeding Latte"
 date: 2015-04-06
 slug: faster-than-speeding-latte
 url: /blog/2015/04/Faster-Than-Speeding-Latte
+evergreen: true
 ---
+
 Check out Brendan Burns racing Kubernetes.
-[![Check out Brendan Burns racing Kubernetes](https://img.youtube.com/vi/7vZ9dRKRMyc/0.jpg)](https://www.youtube.com/watch?v=?7vZ9dRKRMyc)
+
+{{< youtube id="7vZ9dRKRMyc" title="Latte vs. Kubernetes setup - which is faster?">}}

content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md

@@ -1,31 +1,35 @@
 ---
 title: Runc and CVE-2019-5736
 date: 2019-02-11
+evergreen: false # mentions PodSecurityPolicy
 ---
 
+Authors: Kubernetes Product Security Committee
+
 This morning [a container escape vulnerability in runc was announced](https://www.openwall.com/lists/oss-security/2019/02/11/2). We wanted to provide some guidance to Kubernetes users to ensure everyone is safe and secure.
 
-## What Is Runc?
+## What is runc?
 
 Very briefly, runc is the low-level tool which does the heavy lifting of spawning a Linux container. Other tools like Docker, Containerd, and CRI-O sit on top of runc to deal with things like data formatting and serialization, but runc is at the heart of all of these systems.
 
 Kubernetes in turn sits on top of those tools, and so while no part of Kubernetes itself is vulnerable, most Kubernetes installations are using runc under the hood.
 
-### What Is The Vulnerability?
+### What is the vulnerability?
 
 While full details are still embargoed to give people time to patch, the rough version is that when running a process as root (UID 0) inside a container, that process can exploit a bug in runc to gain root privileges on the host running the container. This then allows them unlimited access to the server as well as any other containers on that server.
 
 If the process inside the container is either trusted (something you know is not hostile) or is not running as UID 0, then the vulnerability does not apply. It can also be prevented by SELinux, if an appropriate policy has been applied. RedHat Enterprise Linux and CentOS both include appropriate SELinux permissions with their packages and so are believed to be unaffected if SELinux is enabled.
 
 The most common source of risk is attacker-controller container images, such as unvetted images from public repositories.
 
-### What Should I Do?
+### What should i do?
 
 As with all security issues, the two main options are to mitigate the vulnerability or upgrade your version of runc to one that includes the fix.
 
 As the exploit requires UID 0 within the container, a direct mitigation is to ensure all your containers are running as a non-0 user. This can be set within the container image, or via your pod specification:
 
 ```yaml
+---
 apiVersion: v1
 kind: Pod
 metadata:
@@ -39,6 +43,7 @@ spec:
 This can also be enforced globally using a PodSecurityPolicy:
 
 ```yaml
+---
 apiVersion: policy/v1beta1
 kind: PodSecurityPolicy
 metadata:
@@ -89,7 +94,7 @@ We don't have specific confirmation that Docker for Mac and Docker for Windows a
 
 If you are unable to upgrade Docker, the Rancher team has provided backports of the fix for many older versions at [github.com/rancher/runc-cve](https://github.com/rancher/runc-cve).
 
-## Getting More Information
+## Getting more information
 
 If you have any further questions about how this vulnerability impacts Kubernetes, please join us at [discuss.kubernetes.io](https://discuss.kubernetes.io/).
 

content/en/blog/_posts/2021-04-22-gateway-api/index.md

@@ -30,15 +30,15 @@ This led to design principles that allow the Gateway API to improve upon Ingress
 
 The Gateway API introduces a few new resource types:
 
-- **[GatewayClasses](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.GatewayClass)** are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes.
-- **[Gateways](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.Gateway)** are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs.
-- **Routes** are not a single resource, but represent many different protocol-specific Route resources. The [HTTPRoute](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRoute) has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are [TCPRoutes](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.TCPRoute), [UDPRoutes](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.UDPRoute), and [TLSRoutes](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.TLSRoute) which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future.
+- **[GatewayClasses](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.GatewayClass)** are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes.
+- **[Gateways](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.Gateway)** are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs.
+- **Routes** are not a single resource, but represent many different protocol-specific Route resources. The [HTTPRoute](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRoute) has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are [TCPRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.TCPRoute), [UDPRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.UDPRoute), and [TLSRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.TLSRoute) which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future.
 
 ![The resources of the Gateway API](gateway-api-resources.png)
 
 ### Gateway Controller Implementations
 
-The good news is that although Gateway is in [Alpha](https://github.com/kubernetes-sigs/gateway-api/releases), there are already several [Gateway controller implementations](https://gateway-api.sigs.k8s.io/references/implementations/) that you can run. Since it’s a standardized spec, the following example could be run on any of them and should function the exact same way. Check out [getting started](https://gateway-api.sigs.k8s.io/guides/getting-started/) to see how to install and use one of these Gateway controllers.
+The good news is that although Gateway is in [Alpha](https://github.com/kubernetes-sigs/gateway-api/releases), there are already several [Gateway controller implementations](https://gateway-api.sigs.k8s.io/implementations/) that you can run. Since it’s a standardized spec, the following example could be run on any of them and should function the exact same way. Check out [getting started](https://gateway-api.sigs.k8s.io/v1alpha1/guides/getting-started/) to see how to install and use one of these Gateway controllers.
 
 ## Getting Hands-on with the Gateway API
 
@@ -134,7 +134,7 @@ spec:
 
 So we have two HTTPRoutes matching and routing traffic to different Services. You might be wondering, where are these Services accessible? Through which networks or IPs are they exposed? 
 
-How Routes are exposed to clients is governed by [Route binding](https://gateway-api.sigs.k8s.io/concepts/api-overview/#route-binding), which describes how Routes and Gateways create a bidirectional relationship between each other. When Routes are bound to a Gateway it means their collective routing rules are configured on the underlying load balancers or proxies and the Routes are accessible through the Gateway. Thus, a Gateway is a logical representation of a networking data plane that can be configured through Routes.
+How Routes are exposed to clients is governed by [Route binding](https://gateway-api.sigs.k8s.io/concepts/api-overview/#route-resources), which describes how Routes and Gateways create a bidirectional relationship between each other. When Routes are bound to a Gateway it means their collective routing rules are configured on the underlying load balancers or proxies and the Routes are accessible through the Gateway. Thus, a Gateway is a logical representation of a networking data plane that can be configured through Routes.
 
 
 ![How Routes bind with Gateways](route-binding.png )
@@ -192,6 +192,6 @@ When you put it all together, you have a single load balancing infrastructure th
 
 There are many resources to check out to learn more. 
 
-*   Check out the [user guides](https://gateway-api.sigs.k8s.io/guides/getting-started/) to see what use-cases can be addressed. 
-*   Try out one of the [existing Gateway controllers ](https://gateway-api.sigs.k8s.io/references/implementations/)
+*   Check out the [user guides](https://gateway-api.sigs.k8s.io/v1alpha1/guides/getting-started/) to see what use-cases can be addressed. 
+*   Try out one of the [existing Gateway controllers ](https://gateway-api.sigs.k8s.io/implementations/)
 *   Or [get involved](https://gateway-api.sigs.k8s.io/contributing/community/) and help design and influence the future of Kubernetes service networking!

content/en/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md

@@ -0,0 +1,78 @@
+---
+layout: blog
+title: "Meet Our Contributors - APAC (Aus-NZ region)"
+date: 2022-03-16T12:00:00+0000
+slug: meet-our-contributors-au-nz-ep-02
+canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-au-nz-ep-02/
+---
+
+**Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Brad McCoy](https://github.com/bradmccoydev), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Jayesh Srivastava](https://github.com/jayesh-srivastava), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Priyanka Saggu](github.com/Priyankasaggu11929/), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde)
+
+---
+
+Good day, everyone 👋
+
+Welcome back to the second episode of the "Meet Our Contributors" blog post series for APAC.
+
+This post will feature four outstanding contributors from the Australia and New Zealand regions, who have played diverse leadership and community roles in the Upstream Kubernetes project.
+
+So, without further ado, let's get straight to the blog.
+
+## [Caleb Woodbine](https://github.com/BobyMCbobs)
+
+Caleb Woodbine is currently a member of the ii.nz organisation.
+
+He began contributing to the Kubernetes project in 2018 as a member of the Kubernetes Conformance working group. His experience was positive, and he benefited from early guidance from [Hippie Hacker](https://github.com/hh), a fellow contributor from New Zealand.
+
+He has made major contributions to Kubernetes project since then through `SIG k8s-infra` and `k8s-conformance` working group.
+
+Caleb is also a co-organizer of the [CloudNative NZ](https://www.meetup.com/cloudnative-nz/) community events, which aim to expand the reach of Kubernetes project throughout New Zealand in order to encourage technical education and improved employment opportunities.
+
+> _There need to be more outreach in APAC and the educators and universities must pick up Kubernetes, as they are very slow and about 8+ years out of date. NZ tends to rather pay overseas than educate locals on the latest cloud tech Locally._
+
+## [Dylan Graham](https://github.com/DylanGraham)
+
+Dylan Graham is a cloud engineer from Adeliade, Australia. He has been contributing to the upstream Kubernetes project since 2018.
+
+He stated that being a part of such a large-scale project was initially overwhelming, but that the community's friendliness and openness assisted him in getting through it.
+
+He began by contributing to the project documentation and is now mostly focused on the community support for the APAC region.
+
+He believes that consistent attendance at community/project meetings, taking on project tasks, and seeking community guidance as needed can help new aspiring developers become effective contributors.
+
+> _The feeling of being a part of a large community is really special. I've met some amazing people, even some before the pandemic in real life :)_
+
+## [Hippie Hacker](https://github.com/hh)
+
+Hippie has worked for the CNCF.io as a Strategic Initiatives contractor from New Zealand for almost 5+ years. He is an active contributor to k8s-infra, API conformance testing, Cloud provider conformance submissions, and apisnoop.cncf.io domains of the upstream Kubernetes & CNCF projects.
+
+He recounts their early involvement with the Kubernetes project, which began roughly 5 years ago when their firm, ii.nz, demonstrated [network booting from a Raspberry Pi using PXE and running Gitlab in-cluster to install Kubernetes on servers](https://ii.nz/post/bringing-the-cloud-to-your-community/).
+
+He describes their own contributing experience as someone who, at first, tried to do all of the hard lifting on their own, but eventually saw the benefit of group contributions which reduced burnout and task division which allowed folks to keep moving forward on their own momentum.
+
+He recommends that new contributors use pair programming.
+
+> _The cross pollination of approaches and two pairs of eyes on the same work can often yield a much more amplified effect than a PR comment / approval alone can afford._
+
+## [Nick Young](https://github.com/youngnick)
+
+Nick Young works at VMware as a technical lead for Contour, a CNCF ingress controller. He was active with the upstream Kubernetes project from the beginning, and eventually became the chair of the LTS working group, where he advocated user concerns. He is currently the SIG Network Gateway API subproject's maintainer.
+
+His contribution path was notable in that he began working on major areas of the Kubernetes project early on, skewing his trajectory.
+
+He asserts the best thing a new contributor can do is to "start contributing". Naturally, if it is relevant to their employment, that is excellent; however, investing non-work time in contributing can pay off in the long run in terms of work. He believes that new contributors, particularly those who are currently Kubernetes users, should be encouraged to participate in higher-level project discussions. 
+
+> _Just being active and contributing will get you a long way. Once you've been active for a while, you'll find that you're able to answer questions, which will mean you're asked questions, and before you know it you are an expert._
+
+
+
+
+---
+
+If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. Your suggestions would be much appreciated. We're thrilled to have additional folks assisting us in reaching out to even more wonderful individuals of the community.
+
+
+We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋
+
+
+