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

Merge branch 'master' into release-1.7

Browse Source
This commit is contained in:
steveperry-53
2017-08-04 09:16:33 -07:00
parent 6e8ade49a8 a29cfd7d0c
commit d1e7987476
14 changed files with 50 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files
cn/docs/getting-started-guides/coreos/bare_metal_offline.md
+6 -6
View File
@@ -92,11 +92,11 @@ LABEL local
LOCALBOOT 0
```
至此，您应当已经配置好一个可用的PXELINUX环境用来运行CoreOS节点了，您可以通过在本地运行VirtualBox或者物理裸机来验证这一点。
至此，您应当已经配置好一个可用的PXELINUX环境用来运行CoreOS节点了。您可以使用VirtualBox或者在物理裸机上对PXELINUX环境所提供的服务进行验证。
## 添加CoreOS至PXE
本节将介绍如何在一个现有的PXELINUX环境上设置CoreOS镜像。
本节描述在已有PXELINUX环境的前提下，如何配置CoreOS镜像与之并存。
1. 查找或者创建TFTP根目录，后续所有步骤都将基于此目录。
* 本文中我们假设`/tftpboot`是根目录。
@@ -199,13 +199,13 @@ subnet 10.20.30.0 netmask 255.255.255.0 {
1. 第一种方式是将云配置文件模版化，然后通过编程的方式为不同的集群提供不同的配置。
2. 第二种方式是运行一个服务发现协议从而可以在云环境中做服务的自动发现。
在本demo中，我们仅简单地创建一个静态的单一`etcd`服务器来运行Kubernetes并提供`etcd`的主要服务。
在本示例中，我们将通过静态方式创建一个etcd服务器，用于运行Kubernetes主控组件，并用作etcd主节点。
由于我们的集群处于一个离线的环境中，所以大部分的CoreOS和Kubernetes帮助进程是受限的。为了完成部署，我们需要下载Kubernetes的各种可执行文件到本地然后再启动运行。
由于我们的集群处于一个离线的环境中，所以大部分的CoreOS和Kubernetes帮助进程是受限的。为了完成部署，我们需要下载Kubernetes的各个可执行文件到本地然后再启动运行。
一种简单的方案是在DHCP/TFTP主机上搭建一个简易的web服务器，从而环境中的CoreOS PXE机器可以从其上下载各种可执行文件。
一种简单的方案是在DHCP/TFTP主机上搭建一个简易的web服务器，从而环境中的CoreOS PXE机器可以从其上下载各个可执行文件。
为了达到这一目标，我们将启动一个`apache`服务器并提供运行Kuberetes所需要的各种可执行文件。
为了达到这一目标，我们将启动一个`apache`服务器并提供运行Kubernetes所需要的各个可执行文件。
以下脚本运行在上文中准备好的PXE服务器上：
docs/admin/authorization/rbac.md
+1 -1
View File
@@ -754,7 +754,7 @@ Here are two approaches for managing this transition:
Run both the RBAC and ABAC authorizers, and include the legacy ABAC policy:
```
--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.jsonl
--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json
```
The RBAC authorizer will attempt to authorize requests first. If it denies an API request,
docs/admin/cluster-large.md
+4 -4
View File
@@ -7,11 +7,11 @@ title: Building Large Clusters
## Support
At {{page.version}}, Kubernetes supports clusters with up to 1000 nodes. More specifically, we support configurations that meet *all* of the following criteria:
At {{page.version}}, Kubernetes supports clusters with up to 5000 nodes. More specifically, we support configurations that meet *all* of the following criteria:
* No more than 2000 nodes
* No more than 60000 total pods
* No more than 120000 total containers
* No more than 5000 nodes
* No more than 150000 total pods
* No more than 300000 total containers
* No more than 100 pods per node
<br>
docs/admin/kube-apiserver.md
+1 -1
View File
@@ -129,7 +129,7 @@ TaintBasedEvictions=true|false (ALPHA - default=false)
--storage-media-type string The media type to use to store objects in storage. Some resources or storage backends may only support a specific media type and will ignore this setting. (default "application/vnd.kubernetes.protobuf")
--storage-versions string The per-group version to store resources in. Specified in the format "group1/version1,group2/version2,...". In the case where objects are moved from one group to the other, you may specify the format "group1=group2/v1beta1,group3/v1beta1,...". You only need to pass the groups you wish to change from the defaults. It defaults to a list of preferred versions of all registered groups, which is derived from the KUBE_API_VERSIONS environment variable. (default "admission.k8s.io/v1alpha1,admissionregistration.k8s.io/v1alpha1,apps/v1beta1,authentication.k8s.io/v1,authorization.k8s.io/v1,autoscaling/v1,batch/v1,certificates.k8s.io/v1beta1,componentconfig/v1alpha1,extensions/v1beta1,federation/v1beta1,imagepolicy.k8s.io/v1alpha1,networking.k8s.io/v1,policy/v1beta1,rbac.authorization.k8s.io/v1beta1,settings.k8s.io/v1alpha1,storage.k8s.io/v1,v1")
--target-ram-mb int Memory limit for apiserver in MB (used to configure sizes of caches, etc.)
--tls-ca-file string If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle. Altneratively, the certificate authority can be appended to the certificate provided by --tls-cert-file.
--tls-ca-file string If set, this certificate authority will used for secure access from Admission Controllers. This must be a valid PEM-encoded CA bundle. Alternatively, the certificate authority can be appended to the certificate provided by --tls-cert-file.
--tls-cert-file string File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to /var/run/kubernetes.
--tls-private-key-file string File containing the default x509 private key matching --tls-cert-file.
--tls-sni-cert-key namedCertKey A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". (default [])
docs/concepts/overview/what-is-kubernetes.md
+1 -1
View File
@@ -10,7 +10,7 @@ This page is an overview of Kubernetes.
{% endcapture %}
{% capture body %}
Kubernetes is an [open-source platform for automating deployment, scaling, and operations of application containers](http://www.slideshare.net/BrianGrant11/wso2con-us-2015-kubernetes-a-platform-for-automating-deployment-scaling-and-operations) across clusters of hosts, providing container-centric infrastructure.
Kubernetes is an [open-source platform designed to automate deploying, scaling, and operating application containers](http://www.slideshare.net/BrianGrant11/wso2con-us-2015-kubernetes-a-platform-for-automating-deployment-scaling-and-operations).
With Kubernetes, you are able to quickly and efficiently respond to customer demand:
docs/concepts/services-networking/ingress.md
+1 -1
View File
@@ -79,7 +79,7 @@ __Lines 10-11__: Each http rule contains the following information: A host (e.g.
__Lines 12-14__: A backend is a service:port combination as described in the [services doc](/docs/concepts/services-networking/service/). Ingress traffic is typically sent directly to the endpoints matching a backend.
__Global Parameters__: For the sake of simplicity the example Ingress has no global parameters, see the [api-reference](https://releases.k8s.io/{{page.githubbranch}}/pkg/apis/extensions/v1beta1/types.go) for a full definition of the resource. One can specify a global default backend in the absence of which requests that don't match a path in the spec are sent to the default backend of the Ingress controller.
__Global Parameters__: For the sake of simplicity the example Ingress has no global parameters, see the [API reference](https://releases.k8s.io/{{page.githubbranch}}/staging/src/k8s.io/api/extensions/v1beta1/types.go) for a full definition of the resource. One can specify a global default backend in the absence of which requests that don't match a path in the spec are sent to the default backend of the Ingress controller.
## Ingress controllers
docs/concepts/services-networking/service.md
+2 -2
View File
@@ -338,9 +338,9 @@ For headless services that do not define selectors, the endpoints controller doe
not create `Endpoints` records. However, the DNS system looks for and configures
either:
* CNAME records for `ExternalName`-type services
* CNAME records for `ExternalName`-type services.
* A records for any `Endpoints` that share a name with the service, for all
other types
other types.
## Publishing services - service types
docs/concepts/storage/volumes.md
+4 -4
View File
@@ -289,10 +289,10 @@ spec:
### nfs
An `nfs` volume allows an existing NFS (Network File System) share to be
A `nfs` volume allows an existing NFS (Network File System) share to be
mounted into your pod. Unlike `emptyDir`, which is erased when a Pod is
removed, the contents of an `nfs` volume are preserved and the volume is merely
unmounted. This means that an NFS volume can be pre-populated with data, and
unmounted. This means that a NFS volume can be pre-populated with data, and
that data can be "handed off" between pods. NFS can be mounted by multiple
writers simultaneously.
@@ -322,7 +322,7 @@ See the [iSCSI example](https://github.com/kubernetes/kubernetes/tree/{{page.git
### fc (fibre channel)
An `fc` volume allows an existing fibre channel volume to be mounted into your pod.
A `fc` volume allows an existing fibre channel volume to be mounted into your pod.
You can specify single or multiple target World Wide Names to the parameter
targetWWNs in your volume configuration. If multiple WWNs are specified,
targetWWNs expects that those WWNs form multipath connection.
@@ -365,7 +365,7 @@ See the [GlusterFS example](https://github.com/kubernetes/kubernetes/tree/{{page
### rbd
An `rbd` volume allows a [Rados Block
A `rbd` volume allows a [Rados Block
Device](http://ceph.com/docs/master/rbd/rbd/) volume to be mounted into your
pod. Unlike `emptyDir`, which is erased when a Pod is removed, the contents of
a `rbd` volume are preserved and the volume is merely unmounted. This
docs/concepts/workloads/controllers/deployment.md
+1 -1
View File
@@ -510,7 +510,7 @@ nginx-deployment-618515232 11 11 11 7m
## Pausing and Resuming a Deployment
You can pause a Deployment before triggering one or more updates and then resume it. This will allow you to
apply multiple fixes in between pausing and resuming without triggering unnecesarry rollouts.
apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
For example, with a Deployment that was just created:
```shell
docs/tasks/access-application-cluster/access-cluster.md
+1 -1
View File
@@ -174,7 +174,7 @@ From within a pod the recommended ways to connect to API are:
in any container of the pod can access it. See this [example of using kubectl proxy
in a pod](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/examples/kubectl-container/).
- use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster/main.go)
They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
In each case, the credentials of the pod are used to communicate securely with the apiserver.
docs/tasks/configure-pod-container/configure-volume-storage.md
+17 -17
View File
@@ -35,50 +35,50 @@ restarts. Here is the configuration file for the Pod:
1. Create the Pod:
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml
1. Verify that the Pod's Container is running, and then watch for changes to
the Pod:
kubectl get --watch pod redis
kubectl get --watch pod redis
The output looks like this:
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
1. In another terminal, get a shell to the running Container:
kubectl exec -it redis -- /bin/bash
kubectl exec -it redis -- /bin/bash
1. In your shell, go to `/data/redis`, and create a file:
root@redis:/data/redis# echo Hello > test-file
root@redis:/data/redis# echo Hello > test-file
1. In your shell, list the running processes:
root@redis:/data/redis# ps aux
root@redis:/data/redis# ps aux
The output is similar to this:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379
root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash
root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
redis 1 0.1 0.1 33308 3828 ? Ssl 00:46 0:00 redis-server *:6379
root 12 0.0 0.0 20228 3020 ? Ss 00:47 0:00 /bin/bash
root 15 0.0 0.0 17500 2072 ? R+ 00:48 0:00 ps aux
1. In your shell, kill the redis process:
root@redis:/data/redis# kill <pid>
root@redis:/data/redis# kill <pid>
where `<pid>` is the redis process ID (PID).
1. In your original terminal, watch for changes to the redis Pod. Eventually,
you will see something like this:
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
redis 0/1 Completed 0 6m
redis 1/1 Running 1 6m
NAME READY STATUS RESTARTS AGE
redis 1/1 Running 0 13s
redis 0/1 Completed 0 6m
redis 1/1 Running 1 6m
At this point, the Container has terminated and restarted. This is because the
redis Pod has a
@@ -87,7 +87,7 @@ of `Always`.
1. Get a shell into the restarted Container:
kubectl exec -it redis -- /bin/bash
kubectl exec -it redis -- /bin/bash
1. In your shell, goto `/data/redis`, and verify that `test-file` is still there.
docs/tasks/federation/set-up-cluster-federation-kubefed.md
+9
View File
@@ -61,6 +61,15 @@ sudo cp kubernetes/client/bin/kubectl /usr/local/bin
sudo chmod +x /usr/local/bin/kubectl
```
### Install with snap on Ubuntu
kubefed is available as a [snap](https://snapcraft.io/) application.
1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with:
sudo snap install kubefed --classic
2. Run `kubefed version` to verify that the verison you've installed is sufficiently up-to-date.
## Choosing a host cluster.
docs/tasks/manage-gpus/scheduling-gpus.md
+1 -1
View File
@@ -143,7 +143,7 @@ spec:
## Future
- Support for hardware accelerators is in it's early stages in Kubernetes.
- Support for hardware accelerators is in its early stages in Kubernetes.
- GPUs and other accelerators will soon be a native compute resource across the system.
- Better APIs will be introduced to provision and consume accelerators in a scalable manner.
- Kubernetes will automatically ensure that applications consuming GPUs gets the best possible performance.
docs/tutorials/stateful-application/basic-stateful-set.md
+1 -1
View File
@@ -1006,7 +1006,7 @@ above.
### Parallel Pod Management
`Parallel` pod management tells the StatefulSet controller to launch or
terminate all Pods in parallel, and to not wait for Pods to becoming Running
terminate all Pods in parallel, and not to wait for Pods to become Running
and Ready or completely terminated prior to launching or terminating another
Pod.