Merge branch 'kubernetes:main' into master

Author: ptux

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

content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md

@@ -7,11 +7,16 @@ slug: are-you-ready-for-dockershim-removal
 
 **Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano.
 
+{{% alert color="info" title="Poll closed" %}}
+This poll closed on January 7, 2022.
+{{% /alert %}}
+
 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**.
+
+<del>Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8</del>
 
 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/)
@@ -25,15 +30,15 @@ are still not ready: [migrating telemetry and security agents](/docs/tasks/admin
 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 
+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)**
+<del>We are collecting opinions through this survey: https://forms.gle/svCJmhvTv78jGdSx8</del>
 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

content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md

@@ -0,0 +1,99 @@
+---
+layout: blog
+title: "Kubernetes is Moving on From Dockershim: Commitments and Next Steps"
+date: 2022-01-07
+slug: kubernetes-is-moving-on-from-dockershim
+---
+
+**Authors:** Sergey Kanzhelev (Google), Jim Angel (Google), Davanum Srinivas (VMware), Shannon Kularathna (Google), Chris Short (AWS), Dawn Chen (Google)
+
+Kubernetes is removing dockershim in the upcoming v1.24 release. We're excited
+to reaffirm our community values by supporting open source container runtimes,
+enable a smaller kubelet, and increase engineering velocity for teams using
+Kubernetes. If you [use Docker Engine as a Container Runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)
+for your Kubernetes cluster, get ready to migrate to 1.24! To check if you're
+affected, refer to [Check whether dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/).
+
+## Why we’re moving away from dockershim
+
+Docker was the first container runtime used by Kubernetes. This is one of the
+reasons why Docker is so familiar to many Kubernetes users and enthusiasts.
+As containerization became an industry standard, the Kubernetes project added support
+for additional runtimes. This culminated with the implementation of the
+container runtime interface (CRI), letting system components (like the kubelet)
+talk to container runtimes in a standardized way. As a result, the hardcoded support for Docker –
+a component the project refers to as dockershim – became an anomaly in the Kubernetes project.
+Dependencies on Docker and dockershim have crept into various tools
+and projects in the CNCF ecosystem ecosystem, resulting in fragile code.
+
+By removing the
+dockershim CRI, we're embracing the first value of CNCF: "[Fast is better than
+slow](https://github.com/cncf/foundation/blob/master/charter.md#3-values)".
+Stay tuned for future communications on the topic!
+
+## Deprecation timeline
+
+We [formally announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/) the dockershim deprecation in December 2020.  Full removal is targeted
+in Kubernetes 1.24, in April 2022. This timeline
+aligns with our [deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior),
+which states that deprecated behaviors must function for at least 1 year
+after their announced deprecation.
+
+We'll support Kubernetes version 1.23, which includes
+dockershim, for another year in the Kubernetes project. Managed
+Kubernetes providers, vendor support is likely to last even longer, but this is
+dependent on the companies themselves. Regardless, we're confident all cluster operations will have
+time to migrate. If you have more questions about the dockershim removal, refer
+to the [Dockershim Deprecation FAQ](/dockershim).
+
+We asked you whether you feel prepared for the migration from dockershim in this
+survey: [Are you ready for Dockershim removal](/blog/2021/11/12/are-you-ready-for-dockershim-removal/).
+We had over 600 responses. To everybody who took time filling out the survey,
+thank you.
+
+The results show that we still have a lot of ground to cover to help you to
+migrate smoothly. Other container runtimes exist, and have been promoted
+extensively. However, many users told us they still rely on dockershim,
+and sometimes have dependencies that need to be re-worked. Some of these
+dependencies are outside of your control. Based on the feedback received from
+you, here are some of the steps we are taking to help.
+
+## Our next steps
+
+Based on the feedback you provided:
+
+- CNCF and the 1.24 release team are committed to delivering documentation in
+  time for the 1.24 release. This includes more informative blog posts like this
+  one, updating existing code samples, tutorials, and tasks, and producing a
+  migration guide for cluster operators.
+- We are reaching out to the rest of the CNCF community to help prepare them for
+  this change.
+
+If you're part of a project with dependencies on dockershim, or if you're
+interested in helping with the migration effort, please join us! There's always
+room for more contributors, whether to our transition tools or to our
+documentation. To get started, say hello in
+[#sig-node](https://kubernetes.slack.com/archives/C0BP8PW9G)
+channel on [Kuberentes Slack](https://slack.kubernetes.io/)!
+
+## Final thoughts
+
+As a project, we've already seen cluster operators increasingly adopt of other container runtimes through 2021.
+We believe there are no major blockers to migration. The steps we're taking to
+improve the migration experience will light the path more clearly for you.
+
+We understand that migration from dockershim is yet another action you may need to
+do to keep your Kubernetes infrastructure up to date. For most of you, this step
+will be straightforward and transparent. In some cases, you will encounter
+hiccups or issues. The community has discussed at length whether postponing the
+dockershim removal would be helpful. For example, we recently talked about it in
+the [SIG Node discussion on November 11th](https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#bookmark=id.r77y11bgzid)
+and in the [Kubernetes Steering committee meeting held on December 6th](https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit#bookmark=id.m0ir406av7jx).
+We already [postponed](https://github.com/kubernetes/enhancements/pull/2481/) it once last year because the adoption rate of other
+runtimes was lower than we wanted, which also gave us more time to identify
+potential blocking issues.
+
+At this point, we believe that the value that you (and Kubernetes) gain from
+dockershim removal makes up for the migration effort you'll have. Start planning
+now to avoid surprises. We'll have more updates and guides before Kubernetes
+1.24 is released.

content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md

@@ -0,0 +1,106 @@
+---
+layout: blog
+title: "Meet Our Contributors - APAC (India region)"
+date: 2022-01-10T12:00:00+0000
+slug: meet-our-contributors-india-ep-01
+canonicalUrl: https://kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/
+---
+
+**Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Pritish Samal](https://github.com/CIPHERTron), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde)
+
+**Editor:** [Priyanka Saggu](https://psaggu.com)
+
+---
+
+Good day, everyone 👋
+
+Welcome to the first episode of the APAC edition of the "Meet Our Contributors" blog post series.
+
+
+In this post, we'll introduce you to five amazing folks from the India region who have been actively contributing to the upstream Kubernetes projects in a variety of ways, as well as being the leaders or maintainers of numerous community initiatives.
+
+💫 *Let's get started, so without further ado…* 
+
+
+## [Arsh Sharma](https://github.com/RinkiyaKeDad)
+
+Arsh is currently employed with Okteto as a Developer Experience engineer. As a new contributor, he realised that 1:1 mentorship opportunities were quite beneficial in getting him started with the upstream project.
+
+He is presently a CI Signal shadow on the Kubernetes 1.23 release team. He is also contributing to the SIG Testing and SIG Docs projects, as well as to the [cert-manager](https://github.com/cert-manager/infrastructure) tools development work that is being done under the aegis of SIG Architecture.
+
+To the newcomers, Arsh helps plan their early contributions sustainably.
+
+> _I would encourage folks to contribute in a way that's sustainable. What I mean by that
+> is that it's easy to be very enthusiastic early on and take up more stuff than one can
+> actually handle. This can often lead to burnout in later stages. It's much more sustainable
+> to work on things iteratively._
+
+## [Kunal Kushwaha](https://github.com/kunal-kushwaha)
+
+Kunal Kushwaha is a core member of the Kubernetes marketing council. He is also a CNCF ambassador and one of the founders of the [CNCF Students Program](https://community.cncf.io/cloud-native-students/).. He also served as a Communications role shadow during the 1.22 release cycle.
+
+At the end of his first year, Kunal began contributing to the [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) project. He was then selected to work on the same project as part of Google Summer of Code. Kunal mentored people on the same project, first through Google Summer of Code then through Google Code-in. 
+
+As an open-source enthusiast, he believes that diverse participation in the community is beneficial since it introduces new perspectives and opinions and respect for one's peers. He has worked on various open-source projects, and his participation in communities has considerably assisted his development as a developer.
+
+
+> _I believe if you find yourself in a place where you do not know much about the
+> project, that's a good thing because now you can learn while contributing and the
+> community is there to help you. It has helped me a lot in gaining skills, meeting
+> people from around the world and also helping them. You can learn on the go,
+> you don't have to be an expert. Make sure to also check out no code contributions
+> because being a beginner is a skill and you can bring new perspectives to the
+> organisation._
+
+## [Madhav Jivarajani](https://github.com/MadhavJivrajani)
+
+
+Madhav Jivarajani works on the VMware Upstream Kubernetes stability team. He began contributing to the Kubernetes project in January 2021 and has since made significant contributions to several areas of work under SIG Architecture, SIG API Machinery, and SIG ContribEx (contributor experience).
+
+Among several significant contributions are his recent efforts toward the Archival of [design proposals](https://github.com/kubernetes/community/issues/6055), refactoring the ["groups" codebase](https://github.com/kubernetes/k8s.io/pull/2713) under k8s-infra repository to make it mockable and testable, and improving the functionality of the [GitHub k8s bot](https://github.com/kubernetes/test-infra/issues/23129).
+
+In addition to his technical efforts, Madhav oversees many projects aimed at assisting new contributors. He organises bi-weekly "KEP reading club" sessions to help newcomers understand the process of adding new features, deprecating old ones, and making other key changes to the upstream project. He has also worked on developing [Katacoda scenarios](https://github.com/kubernetes-sigs/contributor-katacoda) to assist new contributors to become acquainted with the process of contributing to k/k. In addition to his current efforts to meet with community members every week, he has organised several [new contributors workshops (NCW)](https://www.youtube.com/watch?v=FgsXbHBRYIc).
+
+> _I initially did not know much about Kubernetes. I joined because the community was
+> super friendly. But what made me stay was not just the people, but the project itself.
+> My solution to not feeling overwhelmed in the community was to gain as much context
+> and knowledge into the topics that I was interested in and were being discussed. And
+> as a result I continued to dig deeper into Kubernetes and the design of it.
+> I am a systems nut & thus Kubernetes was an absolute goldmine for me._
+
+
+## [Rajas Kakodkar](https://github.com/rajaskakodkar)
+
+Rajas Kakodkar currently works at VMware as a Member of Technical Staff. He has been engaged in many aspects of the upstream Kubernetes project since 2019.
+
+He is now a key contributor to the Testing special interest group. He is also active in the SIG Network community. Lately, Rajas has contributed significantly to the [NetworkPolicy++](https://docs.google.com/document/d/1AtWQy2fNa4qXRag9cCp5_HsefD7bxKe3ea2RPn8jnSs/) and [`kpng`](https://github.com/kubernetes-sigs/kpng) sub-projects.
+
+One of the first challenges he ran across was that he was in a different time zone than the upstream project's regular meeting hours. However, async interactions on community forums progressively corrected that problem.
+
+> _I enjoy contributing to Kubernetes not just because I get to work on
+> cutting edge tech but more importantly because I get to work with
+> awesome people and help in solving real world problems._
+
+## [Rajula Vineet Reddy](https://github.com/rajula96reddy)
+
+Rajula Vineet Reddy, a Junior Engineer at CERN, is a member of the Marketing Council team under SIG ContribEx . He also served as a release shadow for SIG Release during the 1.22 and 1.23 Kubernetes release cycles.
+
+He started looking at the Kubernetes project as part of a university project with the help of one of his professors. Over time, he spent a significant amount of time reading the project's documentation, Slack discussions, GitHub issues, and blogs, which helped him better grasp the Kubernetes project and piqued his interest in contributing upstream. One of his key contributions was his assistance with automation in the SIG ContribEx Upstream Marketing subproject.
+
+According to Rajula, attending project meetings and shadowing various project roles are vital for learning about the community.
+
+> _I find the community very helpful and it's always_
+> “you get back as much as you contribute”.
+> _The more involved you are, the more you will understand, get to learn and
+> contribute new things._
+> 
+> _The first step to_ “come forward and start” _is hard. But it's all gonna be
+> smooth after that. Just take that jump._
+
+---
+
+If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. We're thrilled to have other folks assisting us in reaching out to even more wonderful individuals of the community. Your suggestions would be much appreciated.
+
+
+We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋
+