Update 2020-12-02-dockershim-faq.md

Fix grammar
pull/25462/head
bl-ue 2020-12-07 10:35:48 -05:00 committed by GitHub
parent b905af1f34
commit 7947cff95a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 4 deletions

View File

@ -55,7 +55,7 @@ All your existing images will still work exactly the same.
### What about private images?
Also yes. All CRI runtimes support the same pull secrets configuration used in
Yes. All CRI runtimes support the same pull secrets configuration used in
Kubernetes, either via the PodSpec or ServiceAccount.
@ -82,7 +82,7 @@ usability of other container runtimes. As an example, OpenShift 4.x has been
using the [CRI-O] runtime in production since June 2019.
For other examples and references you can look at the adopters of containerd and
cri-o, two container runtimes under the Cloud Native Computing Foundation ([CNCF]).
CRI-O, two container runtimes under the Cloud Native Computing Foundation ([CNCF]).
- [containerd](https://github.com/containerd/containerd/blob/master/ADOPTERS.md)
- [CRI-O](https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md)
@ -110,7 +110,7 @@ provide an end-to-end standard for managing containers.
Thats a complex question and it depends on a lot of factors. If Docker is
working for you, moving to containerd should be a relatively easy swap and
has have strictly better performance and less overhead. However we encourage you
will have strictly better performance and less overhead. However, we encourage you
to explore all the options from the [CNCF landscape] in case another would be an
even better fit for your environment.
@ -129,7 +129,7 @@ common things to consider when migrating are:
- Kubectl plugins that require docker CLI or the control socket
- Kubernetes tools that require direct access to Docker (e.g. kube-imagepuller)
- Configuration of functionality like `registry-mirrors` and insecure registries
- Other support scripts or daemons that expect docker to be available and are run
- Other support scripts or daemons that expect Docker to be available and are run
outside of Kubernetes (e.g. monitoring or security agents)
- GPUs or special hardware and how they integrate with your runtime and Kubernetes