spelling error
Signed-off-by: yanan Lee <energylyn@zju.edu.cn> Incorrect spelling Signed-off-by: yanan Lee <energylyn@zju.edu.cn> spelling error Signed-off-by: yanan Lee <energylyn@zju.edu.cn> Incorrect spelling Signed-off-by: yanan Lee <energylyn@zju.edu.cn> Revert "Incorrect spelling" fix some typos Signed-off-by: Jie Luo <luo612@zju.edu.cn> fix a typo Signed-off-by: Jie Luo <luo612@zju.edu.cn> fix a typo Signed-off-by: Jie Luo <luo612@zju.edu.cn>
This commit is contained in:
yanan Lee
@@ -24,7 +24,7 @@ following diagram:
|
||||
In a typical Kubernetes cluster, the API served on port 443. A TLS connection is
|
||||
established. The API server presents a certificate. This certificate is
|
||||
often self-signed, so `$USER/.kube/config` on the user's machine typically
|
||||
contains the root certficate for the API server's certificate, which when specified
|
||||
contains the root certificate for the API server's certificate, which when specified
|
||||
is used in place of the system default root certificates. This certificate is typically
|
||||
automatically written into your `$USER/.kube/config` when you create a cluster yourself
|
||||
using `kube-up.sh`. If the cluster has multiple users, then the creator needs to share
|
||||
|
||||
@@ -330,7 +330,7 @@ roleRef:
|
||||
|
||||
Finally a `ClusterRoleBinding` may be used to grant permissions in all
|
||||
namespaces. The following `ClusterRoleBinding` allows any user in the group
|
||||
"manager" to read secrets in any namepsace.
|
||||
"manager" to read secrets in any namespace.
|
||||
|
||||
```yaml
|
||||
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
|
||||
|
||||
@@ -92,7 +92,7 @@ an extended period of time (10min but it may change in the future).
|
||||
Cluster autoscaler is configured per instance group (GCE) or node pool (GKE).
|
||||
|
||||
If you are using GCE then you can either enable it while creating a cluster with kube-up.sh script.
|
||||
To configure cluser autoscaler you have to set 3 environment variables:
|
||||
To configure cluster autoscaler you have to set 3 environment variables:
|
||||
|
||||
* `KUBE_ENABLE_CLUSTER_AUTOSCALER` - it enables cluster autoscaler if set to true.
|
||||
* `KUBE_AUTOSCALER_MIN_NODES` - minimum number of nodes in the cluster.
|
||||
|
||||
+1
-1
@@ -77,7 +77,7 @@ For example, a pod with ip `1.2.3.4` in the namespace `default` with a DNS name
|
||||
Currently when a pod is created, its hostname is the Pod's `metadata.name` value.
|
||||
|
||||
With v1.2, users can specify a Pod annotation, `pod.beta.kubernetes.io/hostname`, to specify what the Pod's hostname should be.
|
||||
The Pod annotation, if specified, takes precendence over the Pod's name, to be the hostname of the pod.
|
||||
The Pod annotation, if specified, takes precedence over the Pod's name, to be the hostname of the pod.
|
||||
For example, given a Pod with annotation `pod.beta.kubernetes.io/hostname: my-pod-name`, the Pod will have its hostname set to "my-pod-name".
|
||||
|
||||
With v1.3, the PodSpec has a `hostname` field, which can be used to specify the Pod's hostname. This field value takes precedence over the
|
||||
|
||||
@@ -242,7 +242,7 @@ Once the cluster is up, you can grab the admin credentials from the master node
|
||||
## Environment variables
|
||||
|
||||
There are some environment variables that modify the way that `kubeadm` works. Most users will have no need to set these.
|
||||
These enviroment variables are a short-term solution, eventually they will be integrated in the kubeadm configuration file.
|
||||
These environment variables are a short-term solution, eventually they will be integrated in the kubeadm configuration file.
|
||||
|
||||
| Variable | Default | Description |
|
||||
| --- | --- | --- |
|
||||
|
||||
@@ -9,7 +9,7 @@ title: TLS bootstrapping
|
||||
|
||||
## Overview
|
||||
|
||||
This document describes how to set up TLS client certificate boostrapping for kubelets.
|
||||
This document describes how to set up TLS client certificate bootstrapping for kubelets.
|
||||
Kubernetes 1.4 introduces an experimental API for requesting certificates from a cluster-level
|
||||
Certificate Authority (CA). The first supported use of this API is the provisioning of TLS client
|
||||
certificates for kubelets. The proposal can be found [here](https://github.com/kubernetes/kubernetes/pull/20439)
|
||||
@@ -17,7 +17,7 @@ and progress on the feature is being tracked as [feature #43](https://github.com
|
||||
|
||||
## apiserver configuration
|
||||
|
||||
You must provide a token file which specifies at least one "bootstrap token" assigned to a kubelet boostrap-specific group.
|
||||
You must provide a token file which specifies at least one "bootstrap token" assigned to a kubelet bootstrap-specific group.
|
||||
This group will later be used in the controller-manager configuration to scope approvals in the default approval
|
||||
controller. As this feature matures, you should ensure tokens are bound to an RBAC policy which limits requests
|
||||
using the bootstrap token to only be able to make requests related to certificate provisioning. When RBAC policy
|
||||
|
||||
@@ -78,9 +78,9 @@ kubelet
|
||||
--experimental-allowed-unsafe-sysctls stringSlice Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in *). Use these at your own risk.
|
||||
--experimental-bootstrap-kubeconfig string <Warning: Experimental feature> Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated key and obtained certificate is written to the path specified by --kubeconfig. The certificate and key file will be stored in the directory pointed by --cert-dir.
|
||||
--experimental-cgroups-per-qos Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created.
|
||||
--experimental-check-node-capabilities-before-mount [Experimental] if set true, the kubelet will check the underlying node for required componenets (binaries, etc.) before performing the mount
|
||||
--experimental-check-node-capabilities-before-mount [Experimental] if set true, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount
|
||||
--experimental-cri [Experimental] Enable the Container Runtime Interface (CRI) integration. If --container-runtime is set to "remote", Kubelet will communicate with the runtime/image CRI server listening on the endpoint specified by --remote-runtime-endpoint/--remote-image-endpoint. If --container-runtime is set to "docker", Kubelet will launch a in-process CRI server on behalf of docker, and communicate over a default endpoint.
|
||||
--experimental-fail-swap-on Makes the Kubelet fail to start if swap is enabled on the node. This is a temporary opton to maintain legacy behavior, failing due to swap enabled will happen by default in v1.6.
|
||||
--experimental-fail-swap-on Makes the Kubelet fail to start if swap is enabled on the node. This is a temporary option to maintain legacy behavior, failing due to swap enabled will happen by default in v1.6.
|
||||
--experimental-kernel-memcg-notification If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling.
|
||||
--experimental-mounter-path string [Experimental] Path of mounter binary. Leave empty to use the default mount.
|
||||
--experimental-nvidia-gpus int32 Number of NVIDIA GPU devices on this node. Only 0 (default) and 1 are currently supported.
|
||||
|
||||
@@ -184,7 +184,7 @@ Note that this pod specifies explicit resource *limits* and *requests* so it did
|
||||
default values.
|
||||
|
||||
Note: The *limits* for CPU resource are enforced in the default Kubernetes setup on the physical node
|
||||
that runs the container unless the administrator deploys the kubelet with the folllowing flag:
|
||||
that runs the container unless the administrator deploys the kubelet with the following flag:
|
||||
|
||||
```shell
|
||||
$ kubelet --help
|
||||
|
||||
@@ -330,7 +330,7 @@ for eviction. Instead `DaemonSet` should ideally launch `Guaranteed` pods.
|
||||
`kubelet` has been freeing up disk space on demand to keep the node stable.
|
||||
|
||||
As disk based eviction matures, the following `kubelet` flags will be marked for deprecation
|
||||
in favor of the simpler configuation supported around eviction.
|
||||
in favor of the simpler configuration supported around eviction.
|
||||
|
||||
| Existing Flag | New Flag |
|
||||
| ------------- | -------- |
|
||||
|
||||
@@ -50,7 +50,7 @@ It's enabled by default. It can be disabled:
|
||||
|
||||
### Marking add-on as critical
|
||||
|
||||
To be critical an add-on has to run in `kube-system` namespace (cofigurable via flag)
|
||||
To be critical an add-on has to run in `kube-system` namespace (configurable via flag)
|
||||
and have the following annotations specified:
|
||||
|
||||
* `scheduler.alpha.kubernetes.io/critical-pod` set to empty string
|
||||
|
||||
Reference in New Issue
Block a user