whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge master into dev-1.21 to keep in sync

Browse Source
This commit is contained in:
Victor Palade
2021-03-26 21:26:43 +01:00
parent 9442bf8bbd 3db583a9cd
commit ca046d9b1f
200 changed files with 4310 additions and 2439 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/setup/best-practices/cluster-large.md
+3 -4
View File
@@ -69,10 +69,9 @@ When creating a cluster, you can (using custom tooling):
## Addon resources
Kubernetes [resource limits](/docs/concepts/configuration/manage-resources-containers/)
help to minimise the impact of memory leaks and other ways that pods and containers can
impact on other components. These resource limits can and should apply to
{{< glossary_tooltip text="addon" term_id="addons" >}} just as they apply to application
workloads.
help to minimize the impact of memory leaks and other ways that pods and containers can
impact on other components. These resource limits apply to
{{< glossary_tooltip text="addon" term_id="addons" >}} resources just as they apply to application workloads.
For example, you can set CPU and memory limits for a logging component:
content/en/docs/setup/production-environment/tools/kubespray.md
+1 -1
View File
@@ -68,7 +68,7 @@ Kubespray provides the ability to customize many aspects of the deployment:
* {{< glossary_tooltip term_id="cri-o" >}}
* Certificate generation methods
Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
Kubespray customizations can be made to a [variable file](https://docs.ansible.com/ansible/playbooks_variables.html). If you are getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
### (4/5) Deploy a Cluster
content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+3 -3
View File
@@ -333,7 +333,7 @@ These features were added in Kubernetes v1.15:
##### DNS {#dns-limitations}
* ClusterFirstWithHostNet is not supported for DNS. Windows treats all names with a '.' as a FQDN and skips PQDN resolution
* On Linux, you have a DNS suffix list, which is used when trying to resolve PQDNs. On Windows, we only have 1 DNS suffix, which is the DNS suffix associated with that pod's namespace (mydns.svc.cluster.local for example). Windows can resolve FQDNs and services or names resolvable with just that suffix. For example, a pod spawned in the default namespace, will have the DNS suffix **default.svc.cluster.local**. On a Windows pod, you can resolve both **kubernetes.default.svc.cluster.local** and **kubernetes**, but not the in-betweens, like **kubernetes.default** or **kubernetes.default.svc**.
* On Linux, you have a DNS suffix list, which is used when trying to resolve PQDNs. On Windows, we only have 1 DNS suffix, which is the DNS suffix associated with that pod's namespace (mydns.svc.cluster.local for example). Windows can resolve FQDNs and services or names resolvable with only that suffix. For example, a pod spawned in the default namespace, will have the DNS suffix **default.svc.cluster.local**. On a Windows pod, you can resolve both **kubernetes.default.svc.cluster.local** and **kubernetes**, but not the in-betweens, like **kubernetes.default** or **kubernetes.default.svc**.
* On Windows, there are multiple DNS resolvers that can be used. As these come with slightly different behaviors, using the `Resolve-DNSName` utility for name query resolutions is recommended.
##### IPv6
@@ -363,9 +363,9 @@ There are no differences in how most of the Kubernetes APIs work for Windows. Th
At a high level, these OS concepts are different:
* Identity - Linux uses userID (UID) and groupID (GID) which are represented as integer types. User and group names are not canonical - they are just an alias in `/etc/groups` or `/etc/passwd` back to UID+GID. Windows uses a larger binary security identifier (SID) which is stored in the Windows Security Access Manager (SAM) database. This database is not shared between the host and containers, or between containers.
* Identity - Linux uses userID (UID) and groupID (GID) which are represented as integer types. User and group names are not canonical - they are an alias in `/etc/groups` or `/etc/passwd` back to UID+GID. Windows uses a larger binary security identifier (SID) which is stored in the Windows Security Access Manager (SAM) database. This database is not shared between the host and containers, or between containers.
* File permissions - Windows uses an access control list based on SIDs, rather than a bitmask of permissions and UID+GID
* File paths - convention on Windows is to use `\` instead of `/`. The Go IO libraries typically accept both and just make it work, but when you're setting a path or command line that's interpreted inside a container, `\` may be needed.
* File paths - convention on Windows is to use `\` instead of `/`. The Go IO libraries accept both types of file path separators. However, when you're setting a path or command line that's interpreted inside a container, `\` may be needed.
* Signals - Windows interactive apps handle termination differently, and can implement one or more of these:
* A UI thread handles well-defined messages including WM_CLOSE
* Console apps handle ctrl-c or ctrl-break using a Control Handler