The current command on line 125 throws a permission error. The sudo elevation of rights applies to the containerd command, not the write (>) to a file owned by root.
This is the command as copied from the current page:
student@master:~$ sudo containerd config default > /etc/containerd/config.toml
-bash: /etc/containerd/config.toml: Permission denied
Instead leverage sudo tee. It works and no more error:
student@master:~$ containerd config default | sudo tee /etc/containerd/config.toml
fixing content in tabs on adding-windows-nodes.md
reworking tabbed content on adding-windows-nodes.md
intro-windows-in-kubernetes.md
Updating Windows pause image details
PR feedback for adding-windows-nodes.md
Updating comments got GMSA on containerD
After removing the sections of the page that are not in line with the
content guide, there is little left.
Edit pages that link to removed task to no longer link there.
Redirect using 302 status so that there is a future opportunity to reinstate
the page or something like it.
- Avoid links to removed cluster management task
- Broaden applicability of “Safely Drain A Node”
- Add (stub) cluster upgrade task page
- Add a basic page about upgrading your cluster.
- Add a task page about enabling or disabling HTTP APIs
Update the kubeadm upgrade documentation:
- Re-order the steps to drain / upgrade kubelet/kubectl / uncordon
- Remove the detailed output from apply and plan.
- Use {{ skew ... }} markers so that we can avoid more verbose changes
to the document.
- Apply minor / general cleanup (whitespace, missing ':')
Tidying; also drop details of third-party audit configuration
- aggregated API servers
- remove examples of log shipping with fluentd and Logstash
These examples would find a better home in a blog article or elsewhere
on the web. For example, a new blog article that provides detailed
advice about how to deploy log aggregation, configure log shipping into
the aggregator, and protect the audit logs from tampering.
- Instead of telling the users to remove the flag, tell them
that they can point to a copy of the new CA for --client-ca-file
--cluster-signing-cert-file that is not in a bundle with the old CA.
- Don't reference the kubeadm issue. If sig-auth has a tracking
issue for --client-ca-file / --cmanual-ca-rotation: adjust note for "--client-ca-file"
- Instead of telling the users to remove the --client-ca-file flag,
tell them that they can point to a copy of the new CA.
Mention the same for --cluster-signing-cert-file.
- Don't reference the kubeadm issue. If sig-auth has a tracking
issue for --client-ca-file / --cluster-signing-cert-file and bundles
we can add that at some point.
kubelet can fail to start due to various reason, e.g mismatching cgroup
drivers. Add this step to save user from having to go back and check when
found etcd cluster is not running successfully.
zhaojizhuang