blog post draft: https://docs.google.com/document/d/160edAf2q3-FY8SFNCfEoSWcQ0Y7OUUy4hD7nc-b11n8/edit#

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

@@ -5,6 +5,10 @@ date: 2021-11-12
 slug: are-you-ready-for-dockershim-removal
 ---
 
+{{< note >}}
+This poll will close on January 7, 2022.
+{{</ note >}}
+
 **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/).

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.