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

Changes for move to Netlify (#4464)

Browse Source 
* disable jekyll-redirect-from gem

* add _redirects file

* disable 404 redirect script

* add 301 redirect to test

* retain _redirects file

* Convert redirect_from's to _redirect file. (#4409)

* Remove redirect_from's. (#4424)

* Add 301's to _redirects. (#4427)

* add whitespace before 301

* move redirects in /js/redirects/js to _redirects

* add disabled option for cn redirect

* convert include to array in _config.yml

* enable redirects.js script for legacy support
This commit is contained in:
Andrew Chen
2017-07-28 08:23:11 -07:00
committed by GitHub
parent 130b72927c
commit 2e257d9707
158 changed files with 624 additions and 1011 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/architecture/master-node-communication.md
+12 -17
View File
@@ -4,11 +4,6 @@ assignees:
- roberthbailey
- liggitt
title: Master-Node communication
redirect_from:
- "/docs/admin/master-node-communication/"
- "/docs/admin/master-node-communication.html"
- "/docs/concepts/cluster-administration/master-node-communication/"
- "/docs/concepts/cluster-administration/master-node-communication.html"
---
* TOC
@@ -30,18 +25,18 @@ services). In a typical deployment, the apiserver is configured to listen for
remote connections on a secure HTTPS port (443) with one or more forms of
client [authentication](/docs/admin/authentication/) enabled. One or more forms
of [authorization](/docs/admin/authorization/) should be enabled, especially
if [anonymous requests](/docs/admin/authentication/#anonymous-requests) or
[service account tokens](/docs/admin/authentication/#service-account-tokens)
if [anonymous requests](/docs/admin/authentication/#anonymous-requests) or
[service account tokens](/docs/admin/authentication/#service-account-tokens)
are allowed.
Nodes should be provisioned with the public root certificate for the cluster
such that they can connect securely to the apiserver along with valid client
credentials. For example, on a default GCE deployment, the client credentials
provided to the kubelet are in the form of a client certificate. See
[kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) for
automated provisioning of kubelet client certificates.
provided to the kubelet are in the form of a client certificate. See
[kubelet TLS bootstrapping](/docs/admin/kubelet-tls-bootstrapping/) for
automated provisioning of kubelet client certificates.
Pods that wish to connect to the apiserver can do so securely by leveraging a
Pods that wish to connect to the apiserver can do so securely by leveraging a
service account so that Kubernetes will automatically inject the public root
certificate and a valid bearer token into the pod when it is instantiated.
The `kubernetes` service (in all namespaces) is configured with a virtual IP
@@ -71,23 +66,23 @@ or service through the apiserver's proxy functionality.
The connections from the apiserver to the kubelet are used for fetching logs
for pods, attaching (through kubectl) to running pods, and using the kubelet's
port-forwarding functionality. These connections terminate at the kubelet's
port-forwarding functionality. These connections terminate at the kubelet's
HTTPS endpoint.
By default, the apiserver does not verify the kubelet's serving certificate,
which makes the connection subject to man-in-the-middle attacks, and
which makes the connection subject to man-in-the-middle attacks, and
**unsafe** to run over untrusted and/or public networks.
To verify this connection, use the `--kubelet-certificate-authority` flag to
provide the apiserver with a root certificates bundle to use to verify the
To verify this connection, use the `--kubelet-certificate-authority` flag to
provide the apiserver with a root certificates bundle to use to verify the
kubelet's serving certificate.
If that is not possible, use [SSH tunneling](/docs/admin/master-node-communication/#ssh-tunnels)
between the apiserver and kubelet if required to avoid connecting over an
between the apiserver and kubelet if required to avoid connecting over an
untrusted or public network.
Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/)
should be enabled to secure the kubelet API.
should be enabled to secure the kubelet API.
### apiserver -> nodes, pods, and services
docs/concepts/architecture/nodes.md
+1 -6
View File
@@ -3,11 +3,6 @@ assignees:
- caesarxuchao
- dchen1107
title: Nodes
redirect_from:
- "/docs/admin/node/"
- "/docs/admin/node.html"
- "/docs/concepts/nodes/node/"
- "/docs/concepts/nodes/node.html"
---
* TOC
@@ -68,7 +63,7 @@ The node condition is represented as a JSON object. For example, the following r
]
```
If the Status of the Ready condition is "Unknown" or "False" for longer than the `pod-eviction-timeout`, an argument passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/), all of the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on it. The decision to delete the pods cannot be communicated to the kubelet until it re-establishes communication with the apiserver. In the meantime, the pods which are scheduled for deletion may continue to run on the partitioned node.
If the Status of the Ready condition is "Unknown" or "False" for longer than the `pod-eviction-timeout`, an argument passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/), all of the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on it. The decision to delete the pods cannot be communicated to the kubelet until it re-establishes communication with the apiserver. In the meantime, the pods which are scheduled for deletion may continue to run on the partitioned node.
In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) these unreachable pods from the apiserver. However, in 1.5 and higher, the node controller does not force delete pods until it is confirmed that they have stopped running in the cluster. One can see these pods which may be running on an unreachable node as being in the "Terminating" or "Unknown" states. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from Kubernetes causes all the Pod objects running on it to be deleted from the apiserver, freeing up their names.