Merge branch 'master' into release-1.8
This commit is contained in:
steveperry-53
@@ -755,7 +755,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,
|
||||
|
||||
@@ -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>
|
||||
|
||||
@@ -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 [])
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user