The rest of this paragraph talks about nodes being "machines," whereas this sentence is more specific, referring to virtual machines ("VMs"). The article this sentence points to also uses "machines" and isn't specific to VMs.
Trying to use this flag `--record` in the example leads to the warning:
```
Flag --record has been deprecated, --record will be removed in the future
```
Uppercase Service API object following documentation style guide
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Add mitigation propositions
Add RFC reference for the trailing dot in an absolute DNS name
Co-authored-by: Shannon Kularathna <ax3shannonkularathna@gmail.com>
The how-to docs to create a new namespace already specify this, but I think it's worth mentioning in the overview doc that a namespace name must be an RFC 1123 label, as I didn't initially think to look in the how-to doc for limitations.
Update namespace definition to not use _Virtual Clusters_ as a means of explaining namespaces.
Motif: KubeCon NA 21 Talk on ***"Beyond Namespaces: Virtual Clusters are the Future of Multi-Tenancy - Lukas Gentele, Loft Labs"***
I think adding the "for" word in the below sentence makes more sense.
"This document outlines the various components you need to have "for"
a complete and working Kubernetes cluster."
The description talks about the server one way and the overview text talks about it a bit differently.
This change aligns them and make them easier to understand in my opinion.
* 🐛 Containers don't get their own CPU
This is overly broad, in all default setup containers all share the underlying host CPUs so I wouldn't say they "have their own".
* Change wording to "share of CPU" to more closely reflect reality.
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Readers from several different backgrounds will find it useful to know
about how Kubernetes controls access to its API. Promote this overview
to the Security subsection of Concepts.
We currently have quite some contents duplicated between the concepts
and the reference section, which is not good. This PR is an effort to
remove the duplicated content from the two pages while providing links
for readers to check the reference easily.
* Revise Pod concept
Adapt the existing Pod documentation to suit the Docsy theme, by
promoting the Pod concept itself to /docs/concepts/workloads/pods/
Following on from this, update the Pod Lifecycle page to cover the
lifecycle of a Pod and follow on directly from the Pod concept,
for readers keen to understand things in detail.
This change also removes the automatic contents list from the Pod
overview page. Instead, the new page links to all the pages
inside the Pod section.
* Update links to Pod concept
Link to updated content
* Incorporate Pod concept suggestions
Co-authored-by: Celeste Horgan <celeste@cncf.io>
* Revise StatefulSet suggestion for Pod concept
Co-authored-by: Celeste Horgan <celeste@cncf.io>
Co-authored-by: Celeste Horgan <celeste@cncf.io>
In the lower part of the document `instance` is derived from the `name` field. However, in the beginning of the document the value of the `instance` field is aligned with the `part-of` field. Which seems wrong, reading through the rest of the page.
Signed-off-by: Jens Reimann <jreimann@redhat.com>
Quite some resources have been moved out of the `extensions` API group
since 1.18; the `apps/v1beta1` and `apps/v1beta2` group versions are
also dropped. This PR updates the pages which still reference such API
groups or group versions.
kubectl run starting from 1.18 is creating only Pods and there is no option to
create any other resource. Users should be using kubectl create
commands instead. This update the documentation in all those places
where kubectl create should be used instead or changes description to
reflect the situation.
* Moved "Assigning Pods to Nodes" article to Concepts -> Scheduling and Eviction
* Moved "Taints and Tolerations" article to Concepts -> Scheduling and Eviction
* Updated weight of the "Kubernetes Scheduler" article so it appears first
* Updated redirects
* Replaced links to "Assigning Pods to Nodes" and "Taints and Tolerations" articles
to avoid redirects.
Signed-off-by: Adam Kaplan <adam.kaplan@redhat.com>
- Use glossary shortcodes in Node concept
Add glossary tooltips to help new readers take in unfamiliar concepts.
- Move minion hint to glossary
The page about Node need not mention the former name (minion): it has
been many releases since the name change.
Instead, add a hint to the full glossary definition.
- Use note shortcodes where appropriate
- Order node management section first in concept page
- Drop list of components that act on Nodes
With Operators and CustomResourceDefinitions now common, plus the
cluster API, it's less easy to give a definitive list of components that
interacr with Node objects.
- Tidy old mentions of GA features for Node
- Give node tainting by condition its own section
- Introduce toleration concept before using it
- Mention version in TopologyManager feature state
- Other rewording
- Tidy Node condition table
- Explain SchedulingDisabled synthesized condition
- Drop details of supported versions for NodeRestriction
Assume that cluster version is v1.13 or later
Jay Beale
Kubernetes Prow Robot
Jordan Liggitt
John Kwiatkoski
mtardy
Adrian Ludwin
Anubhav Vardhan
Jefftree
Jizu Sun
sandipanpanda
Tim Bannister
Shabir Mohamed Abdul Samadh
shabirmean
Jizu Sun
naisu
Ramdas Potale
Rey Lejano
Harris Brakmić
David M. Lentz
Qiming Teng
Mengjiao Liu
Shannon Kularathna
vaibhav
Alex
toshokan
Quentin Bisson
Jai Govindani
Mauricio Vásquez
Cristian Klein
Karen Bradshaw
Sergey Kanzhelev
veyu
slashr
AUT0R3V
Mike Gehard
ying
Noah Kantrowitz
Qiming Teng
TAKAHASHI Shuuji
Jens Reimann
Raymond Maugé
Maciej Szulik
Rohit Mohta
Roman Marusyk
cloudmelon
Sebastian Winkler
ialidzhikov
Adam Kaplan