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

Merge branch 'master' into release-1.8

Browse Source
This commit is contained in:
steveperry-53
2017-08-09 10:17:40 -07:00
parent b2eebbbc8c 25f0f09775
commit 1025476fd5
25 changed files with 195 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/architecture/master-node-communication.md
+1 -1
View File
@@ -77,7 +77,7 @@ 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)
If that is not possible, use [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)
between the apiserver and kubelet if required to avoid connecting over an
untrusted or public network.
docs/concepts/overview/working-with-objects/namespaces.md
+1 -1
View File
@@ -82,7 +82,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
## Not All Objects are in a Namespace
Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are
in some namespace. However namespace resources are not themselves in a namespace.
in some namespaces. However namespace resources are not themselves in a namespace.
And low-level resources, such as [nodes](/docs/admin/node) and
persistentVolumes, are not in any namespace. Events are an exception: they may or may not
have a namespace, depending on the object the event is about.
docs/concepts/services-networking/connect-applications-service.md
+1 -1
View File
@@ -101,7 +101,7 @@ Kubernetes supports 2 primary modes of finding a Service - environment variables
### Environment Variables
When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx pods (your pod name will be different):
When a Pod runs on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx pods (your pod name will be different):
```shell
$ kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
docs/concepts/workloads/controllers/daemonset.md
+1 -1
View File
@@ -93,7 +93,7 @@ Normally, the machine that a pod runs on is selected by the Kubernetes scheduler
created by the Daemon controller have the machine already selected (`.spec.nodeName` is specified
when the pod is created, so it is ignored by the scheduler). Therefore:
- the [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected
- The [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected
by the DaemonSet controller.
- DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster
bootstrap.
docs/concepts/workloads/controllers/statefulset.md
+3 -3
View File
@@ -94,10 +94,9 @@ spec:
volumeClaimTemplates:
- metadata:
name: www
annotations:
volume.beta.kubernetes.io/storage-class: anything
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: my-storage-class
resources:
requests:
storage: 1Gi
@@ -143,7 +142,8 @@ Note that Cluster Domain will be set to `cluster.local` unless
Kubernetes creates one [PersistentVolume](/docs/concepts/storage/volumes/) for each
VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume
with a storage class of `anything` and 1 Gib of provisioned storage. When a Pod is (re)scheduled
with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass
is specified, then the default StorageClass will be used. When a Pod is (re)scheduled
onto a node, its `volumeMounts` mount the PersistentVolumes associated with its
PersistentVolume Claims. Note that, the PersistentVolumes associated with the
Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted.
docs/concepts/workloads/pods/init-containers.md
+1 -1
View File
@@ -83,7 +83,7 @@ Here are some ideas for how to use Init Containers:
* Wait for some time before starting the app Container with a command like `sleep 60`.
* Clone a git repository into a volume.
* Place values into a configuration file and run a template tool to dynamically
generate a configuration file for the the main app Container. For example,
generate a configuration file for the main app Container. For example,
place the POD_IP value in a configuration and generate the main app
configuration file using Jinja.