Merge branch 'master' into release-1.8
This commit is contained in:
steveperry-53
@@ -17,11 +17,11 @@ following diagram:
|
||||
|
||||
## Transport Security
|
||||
|
||||
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
|
||||
In a typical Kubernetes cluster, the API serves on port 443.
|
||||
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 certificate for the API server's certificate, which when specified
|
||||
is used in place of the system default root certificates. This certificate is typically
|
||||
is used in place of the system default root certificate. 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
|
||||
the certificate with other users.
|
||||
|
||||
@@ -109,7 +109,7 @@ TaintBasedEvictions=true|false (ALPHA - default=false)
|
||||
--oidc-issuer-url string The URL of the OpenID issuer, only HTTPS scheme will be accepted. If set, it will be used to verify the OIDC JSON Web Token (JWT).
|
||||
--oidc-username-claim string The OpenID claim to use as the user name. Note that claims other than the default ('sub') is not guaranteed to be unique and immutable. This flag is experimental, please see the authentication documentation for further details. (default "sub")
|
||||
--profiling Enable profiling via web interface host:port/debug/pprof/ (default true)
|
||||
--proxy-client-cert-file string Client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins. It is expected that this cert includes a signature from the CA in the --requestheader-client-ca-file flag. That CA is published in the 'extension-apiserver-authentication' configmap in the kube-system namespace. Components recieving calls from kube-aggregator should use that CA to perform their half of the mutual TLS verification.
|
||||
--proxy-client-cert-file string Client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins. It is expected that this cert includes a signature from the CA in the --requestheader-client-ca-file flag. That CA is published in the 'extension-apiserver-authentication' configmap in the kube-system namespace. Components receiving calls from kube-aggregator should use that CA to perform their half of the mutual TLS verification.
|
||||
--proxy-client-key-file string Private key for the client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins.
|
||||
--repair-malformed-updates If true, server will do its best to fix the update request to pass the validation, e.g., setting empty UID in update request to its existing value. This flag can be turned off after we fix all the clients that send malformed updates. (default true)
|
||||
--requestheader-allowed-names stringSlice List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.
|
||||
|
||||
@@ -7,7 +7,7 @@ kubefed controls a Kubernetes Cluster Federation
|
||||
|
||||
kubefed controls a Kubernetes Cluster Federation.
|
||||
|
||||
Find more information at https://github.com/kubernetes/kubernetes.
|
||||
Find more information at [https://github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes).
|
||||
|
||||
```
|
||||
kubefed
|
||||
|
||||
@@ -97,7 +97,7 @@ The following guides explain some of the resources in detail:
|
||||
* [Secrets](/docs/tasks/administer-federation/secret/)
|
||||
* [Services](/docs/concepts/cluster-administration/federation-service-discovery/)
|
||||
|
||||
[API reference docs](/docs/federation/api-reference/) lists all the
|
||||
[API reference docs](/docs/reference/federation/) lists all the
|
||||
resources supported by federation apiserver.
|
||||
|
||||
## Cascading deletion
|
||||
|
||||
@@ -651,7 +651,7 @@ Now make the pods:
|
||||
}
|
||||
```
|
||||
|
||||
Both containers will have the following files present on their filesystems:
|
||||
Both containers will have the following files present on their filesystems with the values for each container's environment:
|
||||
|
||||
```shell
|
||||
/etc/secret-volume/username
|
||||
|
||||
@@ -27,7 +27,7 @@ Familiarity with [pods](/docs/user-guide/pods) is suggested.
|
||||
## Background
|
||||
|
||||
Docker also has a concept of
|
||||
[volumes](https://docs.docker.com/userguide/dockervolumes/), though it is
|
||||
[volumes](https://docs.docker.com/engine/admin/volumes/), though it is
|
||||
somewhat looser and less managed. In Docker, a volume is simply a directory on
|
||||
disk or in another container. Lifetimes are not managed and until very
|
||||
recently there were only local-disk-backed volumes. Docker now provides volume
|
||||
|
||||
@@ -28,13 +28,13 @@ different flags and/or different memory and cpu requests for different hardware
|
||||
|
||||
### Create a DaemonSet
|
||||
|
||||
You can describe a DaemonSet in a YAML file. For example, the deamonset.yaml file below describes a DaemonSet that runs the fluentd-elasticsearch Docker image:
|
||||
You can describe a DaemonSet in a YAML file. For example, the daemonset.yaml file below describes a DaemonSet that runs the fluentd-elasticsearch Docker image:
|
||||
|
||||
{% include code.html language="yaml" file="deamonset.yaml" ghlink="/docs/concepts/workloads/controllers/deamonset.yaml" %}
|
||||
{% include code.html language="yaml" file="daemonset.yaml" ghlink="/docs/concepts/workloads/controllers/daemonset.yaml" %}
|
||||
|
||||
* Create a DaemonSet based on the YAML file:
|
||||
```
|
||||
kubectl create -f deamonset.yaml
|
||||
kubectl create -f daemonset.yaml
|
||||
```
|
||||
|
||||
### Required Fields
|
||||
|
||||
@@ -259,7 +259,7 @@ You cannot update any field of the PetSet except `spec.replicas` and the `contai
|
||||
You can scale a PetSet by updating the "replicas" field. Note however that the controller will only:
|
||||
|
||||
1. Create one pet at a time, in order from {0..N-1}, and wait till each one is in [Running and Ready](/docs/user-guide/pod-states) before creating the next
|
||||
2. Delete one pet at a time, in reverse order from {N-1..0}, and wait till each one is completely shutdown (past its [terminationGracePeriodSeconds](/docs/user-guide/pods/index#termination-of-pods)) before deleting the next
|
||||
2. Delete one pet at a time, in reverse order from {N-1..0}, and wait till each one is completely shutdown (past its [terminationGracePeriodSeconds](/docs/concepts/workloads/pods/pod/#termination-of-pods) before deleting the next
|
||||
|
||||
```shell
|
||||
$ kubectl get po
|
||||
@@ -380,7 +380,7 @@ pod "web-0" deleted
|
||||
pod "web-1" deleted
|
||||
```
|
||||
|
||||
Deleting the pods will *not* delete the volumes. Until we finalize the recycle policy for these volumes they will have to get cleaned up by an admin. This is to ensure that you have the chance to copy data off the volume before deleting it. Simply deleting the PVC after the pods have left the [terminating state](/docs/user-guide/pods/index#termination-of-pods) should trigger deletion of the backing Persistent Volumes.
|
||||
Deleting the pods will *not* delete the volumes. Until we finalize the recycle policy for these volumes they will have to get cleaned up by an admin. This is to ensure that you have the chance to copy data off the volume before deleting it. Simply deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) should trigger deletion of the backing Persistent Volumes.
|
||||
|
||||
**Note: you will lose all your data once the PVC is deleted, do this with caution.**
|
||||
|
||||
|
||||
@@ -88,7 +88,7 @@ Here are some ideas for how to use Init Containers:
|
||||
configuration file using Jinja.
|
||||
|
||||
More detailed usage examples can be found in the [StatefulSets documentation](/docs/concepts/abstractions/controllers/statefulsets/)
|
||||
and the [Production Pods guide](/docs/user-guide/production-pods.md#handling-initialization).
|
||||
and the [Production Pods guide](/docs/tasks/#handling-initialization).
|
||||
|
||||
### Init Containers in use
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ title: Fedora (Multi Node)
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
This document describes how to deploy Kubernetes on multiple hosts to set up a multi-node cluster and networking with flannel. Follow fedora [getting started guide](/docs/getting-started-guides/fedora/fedora_manual_config/) to setup 1 master (fed-master) and 2 or more nodes. Make sure that all nodes have different names (fed-node1, fed-node2 and so on) and labels (fed-node1-label, fed-node2-label, and so on) to avoid any conflict. Also make sure that the Kubernetes master host is running etcd, kube-controller-manager, kube-scheduler, and kube-apiserver services, and the nodes are running docker, kube-proxy and kubelet services. Now install flannel on Kubernetes nodes. flannel on each node configures an overlay network that docker uses. flannel runs on each node to setup a unique class-C container network.
|
||||
This document describes how to deploy Kubernetes on multiple hosts to set up a multi-node cluster and networking with flannel. Follow fedora [getting started guide](/docs/getting-started-guides/fedora/fedora_manual_config/) to setup 1 master (fed-master) and 2 or more nodes. Make sure that all nodes have different names (fed-node1, fed-node2 and so on) and labels (fed-node1-label, fed-node2-label, and so on) to avoid any conflict. Also make sure that the Kubernetes master host is running etcd, kube-controller-manager, kube-scheduler, and kube-apiserver services, and the nodes are running docker, kube-proxy and kubelet services. Now install flannel on Kubernetes nodes. Flannel on each node configures an overlay network that docker uses. Flannel runs on each node to setup a unique class-C container network.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
||||
@@ -101,6 +101,7 @@ To be able to work with the docker daemon on your mac/linux host use the `docker
|
||||
eval $(minikube docker-env)
|
||||
```
|
||||
you should now be able to use docker on the command line on your host mac/linux machine talking to the docker daemon inside the minikube VM:
|
||||
|
||||
```
|
||||
docker ps
|
||||
```
|
||||
|
||||
@@ -47,7 +47,7 @@ so we can find them.
|
||||
|
||||
Deployment of the cluster is [supported on a wide variety of public clouds](#cloud-compatibility), private OpenStack clouds, or raw bare metal clusters. Bare metal deployments are supported via [MAAS](http://maas.io/).
|
||||
|
||||
After deciding which cloud to deploy to, follow the [cloud setup page](https://jujucharms.com/docs/devel/getting-started-general#2.-choose-a-cloud) to configure deploying to that cloud.
|
||||
After deciding which cloud to deploy to, follow the [cloud setup page](https://jujucharms.com/docs/devel/getting-started) to configure deploying to that cloud.
|
||||
|
||||
Load your [cloud credentials](https://jujucharms.com/docs/2.0/credentials) for each
|
||||
cloud provider you would like to use.
|
||||
|
||||
@@ -19,7 +19,7 @@ Kubernetes-friendly SDN you want. Currently this means support for Flannel.
|
||||
## Usage
|
||||
|
||||
The flannel charm is a
|
||||
[subordinate](https://jujucharms.com/docs/stable/authors-subordinate-services).
|
||||
[subordinate](https://jujucharms.com/docs/stable/authors-subordinate-applications).
|
||||
This charm will require a principal charm that implements the `kubernetes-cni`
|
||||
interface in order to properly deploy.
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ This page also describes how to configure and get started with the cloud provide
|
||||
|
||||
To start using Kubernetes on top of vSphere and use the vSphere Cloud Provider use Kubernetes-Anywhere. Kubernetes-Anywhere will deploy and configure a cluster from scratch.
|
||||
|
||||
Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/README.md) page
|
||||
Detailed steps can be found at the [getting started with Kubernetes-Anywhere on vSphere](https://git.k8s.io/kubernetes-anywhere/phase1/vsphere/README.md) page.
|
||||
|
||||
### vSphere Cloud Provider
|
||||
|
||||
@@ -31,9 +31,9 @@ vSphere Cloud Provider allows using vSphere managed storage within Kubernetes. I
|
||||
3. Storage Classes and provisioning of volumes.
|
||||
4. vSphere Storage Policy Based Management for Containers orchestrated by Kubernetes.
|
||||
|
||||
Documentation for how to use vSphere managed storage can be found in the [persistent volumes user guide](/docs/concepts/storage/persistent-volumes/#vsphere) and the [volumes user guide](/docs/concepts/storage/volumes/#vspherevolume)
|
||||
Documentation for how to use vSphere managed storage can be found in the [persistent volumes user guide](/docs/concepts/storage/persistent-volumes/#vsphere) and the [volumes user guide](/docs/concepts/storage/volumes/#vspherevolume).
|
||||
|
||||
Examples can be found [here](https://git.k8s.io/kubernetes/examples/volumes/vsphere)
|
||||
Examples can be found [here](https://git.k8s.io/kubernetes/examples/volumes/vsphere).
|
||||
|
||||
#### Enable vSphere Cloud Provider
|
||||
|
||||
@@ -41,15 +41,15 @@ If a Kubernetes cluster has not been deployed using Kubernetes-Anywhere, follow
|
||||
|
||||
**Step-1** [Create a VM folder](https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.vcenterhost.doc/GUID-031BDB12-D3B2-4E2D-80E6-604F304B4D0C.html) and move Kubernetes Node VMs to this folder.
|
||||
|
||||
**Step-2** Make sure Node VM names must comply with the regex `[a-z](([-0-9a-z]+)?[0-9a-z])?(\.[a-z0-9](([-0-9a-z]+)?[0-9a-z])?)*` If Node VMs does not comply with this regex, rename them and make it compliant to this regex.
|
||||
**Step-2** Make sure Node VM names must comply with the regex `[a-z](([-0-9a-z]+)?[0-9a-z])?(\.[a-z0-9](([-0-9a-z]+)?[0-9a-z])?)*`. If Node VMs do not comply with this regex, rename them and make it compliant to this regex.
|
||||
|
||||
Node VM names constraints:
|
||||
|
||||
* VM names can not begin with numbers.
|
||||
* VM names can not have capital letters, any special characters except `.` and `-`.
|
||||
* VM names can not be shorter than 3 chars and longer than 63
|
||||
* VM names can not be shorter than 3 chars and longer than 63.
|
||||
|
||||
**Step-3** Enable disk UUID on Node virtual machines
|
||||
**Step-3** Enable disk UUID on Node virtual machines.
|
||||
|
||||
The disk.EnableUUID parameter must be set to "TRUE" for each Node VM. This step is necessary so that the VMDK always presents a consistent UUID to the VM, thus allowing the disk to be mounted properly.
|
||||
|
||||
@@ -114,7 +114,7 @@ vSphere Cloud Provider requires the following minimal set of privileges to inter
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
**Step-5** Create the vSphere cloud config file (`vsphere.conf`). Cloud config template can be found [here](https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/vsphere/vsphere.conf)
|
||||
**Step-5** Create the vSphere cloud config file (`vsphere.conf`). Cloud config template can be found [here](https://github.com/kubernetes/kubernetes-anywhere/blob/master/phase1/vsphere/vsphere.conf).
|
||||
|
||||
This config file needs to be placed in the shared directory which should be accessible from kubelet container, controller-manager pod, and API server pod.
|
||||
|
||||
@@ -138,7 +138,7 @@ This config file needs to be placed in the shared directory which should be acce
|
||||
|
||||
Note: **```vm-name``` parameter is introduced in 1.6.4 release.** Both ```vm-uuid``` and ```vm-name``` are optional parameters. If ```vm-name``` is specified then ```vm-uuid``` is not used. If both are not specified then kubelet will get vm-uuid from `/sys/class/dmi/id/product_serial` and query vCenter to find the Node VM's name.
|
||||
|
||||
**```vsphere.conf``` for Worker Nodes:** (Only Applicable to 1.6.4 release and above. For older releases this file should have all the parameters specified in Master node's ```vSphere.conf``` file)
|
||||
**```vsphere.conf``` for Worker Nodes:** (Only Applicable to 1.6.4 release and above. For older releases this file should have all the parameters specified in Master node's ```vSphere.conf``` file).
|
||||
|
||||
```
|
||||
[Global]
|
||||
@@ -184,7 +184,7 @@ Below is summary of supported parameters in the `vsphere.conf` file
|
||||
--cloud-config=<Path of the vsphere.conf file>
|
||||
```
|
||||
|
||||
Manifest files for API server and controller-manager are generally located at `/etc/kubernetes`
|
||||
Manifest files for API server and controller-manager are generally located at `/etc/kubernetes`.
|
||||
|
||||
**Step-7** Restart Kubelet on all nodes.
|
||||
* Reload kubelet systemd unit file using ```systemctl daemon-reload```
|
||||
|
||||
@@ -542,8 +542,24 @@ You may have trouble in the configuration if you see Pod statuses like `RunConta
|
||||
|
||||
[ubuntu-vagrantfile]: https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11)
|
||||
|
||||
As with all Kubernetes troubleshooting, normal commands you can take advantage of to help diagnose
|
||||
what happened are `kubectl describe pod` or `kubectl logs`. Example usage:
|
||||
1. The following error indicates a possible certificate mismatch.
|
||||
|
||||
```
|
||||
# kubectl get po
|
||||
Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
|
||||
```
|
||||
|
||||
Verify that the `$HOME/.kube/config` file contains a valid certificate, and regenerate a certificate if necessary.
|
||||
Another workaround is to overwrite the default `kubeconfig` for the "admin" user:
|
||||
|
||||
```
|
||||
mv $HOME/.kube $HOME/.kube.bak
|
||||
mkdir -p $HOME/.kube
|
||||
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
|
||||
sudo chown $(id -u):$(id -g) $HOME/.kube/config
|
||||
```
|
||||
|
||||
The `kubectl describe pod` or `kubectl logs` commands can help you diagnose errors. For example:
|
||||
|
||||
```bash
|
||||
kubectl -n ${NAMESPACE} describe pod ${POD_NAME}
|
||||
|
||||
@@ -241,7 +241,7 @@ kubectl delete namespace constraints-cpu-example
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
|
||||
|
||||
@@ -153,7 +153,7 @@ it can be allowed to run in a namespace that is restricted by a quota.
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
|
||||
@@ -243,7 +243,7 @@ kubectl delete namespace constraints-mem-example
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
|
||||
|
||||
@@ -145,7 +145,7 @@ kubectl delete namespace quota-object-example
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
|
||||
|
||||
@@ -150,7 +150,7 @@ kubectl delete namespace quota-mem-cpu-example
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
|
||||
|
||||
@@ -111,7 +111,7 @@ kubectl delete namespace quota-pod-example
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
|
||||
|
||||
@@ -151,7 +151,7 @@ The scheduler treats `Allocatable` as the available `capacity` for pods.
|
||||
`kubelet` enforce `Allocatable` across pods by default. Enforcement is performed
|
||||
by evicting pods whenever the overall usage across all pods exceeds
|
||||
`Allocatable`. More details on eviction policy can be found
|
||||
[here](./out-of-resource.md#eviction-policy) This enforcement is controlled by
|
||||
[here](./out-of-resource.md#eviction-policy). This enforcement is controlled by
|
||||
specifying `pods` value to the kubelet flag `--enforce-node-allocatable`.
|
||||
|
||||
|
||||
|
||||
@@ -253,7 +253,7 @@ kubectl delete namespace cpu-example
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
|
||||
|
||||
@@ -163,7 +163,7 @@ namespace: 7 bytes
|
||||
|
||||
## Add ImagePullSecrets to a service account
|
||||
|
||||
First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)
|
||||
First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
|
||||
Next, verify it has been created. For example:
|
||||
|
||||
```shell
|
||||
|
||||
@@ -244,7 +244,7 @@ kubectl delete namespace qos-example
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](/docs/tasks/administer-cluster/memory-default-namespace/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
|
||||
|
||||
@@ -129,8 +129,8 @@ Here are some examples:
|
||||
{% capture whatsnext %}
|
||||
|
||||
* Learn more about [containers and commands](/docs/user-guide/containers/).
|
||||
* Learn more about [configuring containers](/docs/user-guide/configuring-containers/).
|
||||
* Learn more about [running commands in a container](/docs/tasks/kubectl/get-shell-running-container/).
|
||||
* Learn more about [configuring pods and containers](/docs/tasks/).
|
||||
* Learn more about [running commands in a container](/docs/tasks/debug-application-cluster/get-shell-running-container/).
|
||||
* See [Container](/docs/api-reference/{{page.version}}/#container-v1-core).
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
@@ -174,7 +174,7 @@ tree, then change directory to `examples/job/work-queue-1`.
|
||||
Otherwise, make a temporary directory, change to it,
|
||||
download the [Dockerfile](Dockerfile?raw=true),
|
||||
and [worker.py](worker.py?raw=true). In either case,
|
||||
build the image with this command: `
|
||||
build the image with this command:
|
||||
|
||||
```shell
|
||||
$ docker build -t job-wq-1 .
|
||||
|
||||
@@ -170,7 +170,7 @@ The output can be saved to a file, like this:
|
||||
cat job.yaml.jinja2 | render_template > jobs.yaml
|
||||
```
|
||||
|
||||
or sent directly to kubectl, like this:
|
||||
Or sent directly to kubectl, like this:
|
||||
|
||||
```shell
|
||||
cat job.yaml.jinja2 | render_template | kubectl create -f -
|
||||
@@ -180,7 +180,7 @@ cat job.yaml.jinja2 | render_template | kubectl create -f -
|
||||
|
||||
If you have a large number of job objects, you may find that:
|
||||
|
||||
- even using labels, managing so many Job objects is cumbersome.
|
||||
- Even using labels, managing so many Job objects is cumbersome.
|
||||
- You exceed resource quota when creating all the Jobs at once,
|
||||
and do not want to wait to create them incrementally.
|
||||
- You need a way to easily scale the number of pods running
|
||||
@@ -188,7 +188,7 @@ If you have a large number of job objects, you may find that:
|
||||
compute resources. Another would be to limit the number of
|
||||
concurrent requests to a shared resource, such as a database,
|
||||
used by all the pods in the job.
|
||||
- very large numbers of jobs created at once overload the
|
||||
- Very large numbers of jobs created at once overload the
|
||||
Kubernetes apiserver, controller, or scheduler.
|
||||
|
||||
In this case, you can consider one of the
|
||||
|
||||
@@ -54,7 +54,7 @@ kubectl delete pods -l app=myapp
|
||||
|
||||
### Persistent Volumes
|
||||
|
||||
Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/user-guide/pods/index#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
|
||||
Deleting the Pods in a StatefulSet will not delete the associated volumes. This is to ensure that you have the chance to copy data off the volume before deleting it. Deleting the PVC after the pods have left the [terminating state](/docs/concepts/workloads/pods/pod/#termination-of-pods) might trigger deletion of the backing Persistent Volumes depending on the storage class and reclaim policy. You should never assume ability to access a volume after claim deletion.
|
||||
|
||||
**Note: Use caution when deleting a PVC, as it may lead to data loss.**
|
||||
|
||||
|
||||
@@ -42,7 +42,7 @@ Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is u
|
||||
* The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver.
|
||||
* Force deletion of the Pod by the user.
|
||||
|
||||
The recommended best practice is to use the first or second approach. If a Node is confirmed to be dead (e.g. permanently disconnected from the network, powered down, etc), then delete the node object. If the node is suffering from a network partition, then try to resolve this or wait for it to resolve. When the partition heals, the kubelet will complete the deletion of the Pod and free up its name in the apiserver.
|
||||
The recommended best practice is to use the first or second approach. If a Node is confirmed to be dead (e.g. permanently disconnected from the network, powered down, etc), then delete the Node object. If the Node is suffering from a network partition, then try to resolve this or wait for it to resolve. When the partition heals, the kubelet will complete the deletion of the Pod and free up its name in the apiserver.
|
||||
|
||||
Normally, the system completes the deletion once the Pod is no longer running on a Node, or the Node is deleted by an administrator. You may override this by force deleting the Pod.
|
||||
|
||||
|
||||
@@ -160,7 +160,7 @@ Run a MySQL client to connect to the server:
|
||||
kubectl run -it --rm --image=mysql:5.6 mysql-client -- mysql -h <pod-ip> -p <password>
|
||||
```
|
||||
|
||||
This command creates a new Pod in the cluster running a mysql client
|
||||
This command creates a new Pod in the cluster running a MySQL client
|
||||
and connects it to the server through the Service. If it connects, you
|
||||
know your stateful MySQL database is up and running.
|
||||
|
||||
|
||||
@@ -71,7 +71,7 @@ EOF
|
||||
Where `172.168.0.24` is the service's cluster IP,
|
||||
`my-svc.my-namespace.svc.cluster.local` is the service's DNS name,
|
||||
`10.0.34.2` is the pod's IP and `my-pod.my-namespace.pod.cluster.local`
|
||||
is the pod's DNS name. you should see the following output:
|
||||
is the pod's DNS name. You should see the following output:
|
||||
|
||||
```
|
||||
2017/03/21 06:48:17 [INFO] generate received request
|
||||
|
||||
@@ -31,7 +31,7 @@ title: Using a Service to Expose Your App
|
||||
|
||||
<p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-config-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>
|
||||
|
||||
<p>Although Pods each have a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>
|
||||
<p>Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>
|
||||
<ul>
|
||||
<li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>
|
||||
<li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code><NodeIP>:<NodePort></code>. Superset of ClusterIP.</li>
|
||||
|
||||
@@ -61,12 +61,12 @@ This tutorial shows you how to build and deploy a simple, multi-tier web applica
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
Download the following configuration files:
|
||||
|
||||
1. [redis-master-deployment.yaml](https://kubernetes.io/docs/tutorials/docs/tutorials/stateless-application/redis-master-deployment.yaml)
|
||||
1. [redis-master-service.yaml](https://kubernetes.io/docs/tutorials/docs/tutorials/stateless-application/redis-master-service.yaml)
|
||||
1. [redis-slave-deployment.yaml](https://kubernetes.io/docs/tutorials/docs/tutorials/stateless-application/redis-slave-deployment.yaml)
|
||||
1. [redis-slave-service.yaml](https://kubernetes.io/docs/tutorials/docs/tutorials/stateless-application/redis-slave-service.yaml)
|
||||
1. [frontend-deployment.yaml](https://kubernetes.io/docs/tutorials/docs/tutorials/stateless-application/frontend-deployment.yaml)
|
||||
1. [frontend-service.yaml](https://kubernetes.io/docs/tutorials/docs/tutorials/stateless-application/frontend-service.yaml)
|
||||
1. [redis-master-deployment.yaml](/docs/tutorials/stateless-application/guestbook/redis-master-deployment.yaml)
|
||||
1. [redis-master-service.yaml](/docs/tutorials/stateless-application/guestbook/redis-master-service.yaml)
|
||||
1. [redis-slave-deployment.yaml](/docs/tutorials/stateless-application/guestbook/redis-slave-deployment.yaml)
|
||||
1. [redis-slave-service.yaml](/docs/tutorials/stateless-application/guestbook/redis-slave-service.yaml)
|
||||
1. [frontend-deployment.yaml](/docs/tutorials/stateless-application/guestbook/frontend-deployment.yaml)
|
||||
1. [frontend-service.yaml](/docs/tutorials/stateless-application/guestbook/frontend-service.yaml)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
@@ -335,4 +335,4 @@ Deleting the Deployments and Services also deletes any running Pods. Use labels
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
[]()
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
<!-- END MUNGE: GENERATED_ANALYTICS -->
|
||||
|
||||
@@ -53,7 +53,7 @@ kubectl run [-i] [--tty] --attach <name> --image=<image>
|
||||
|
||||
Unlike `docker run ...`, if `--attach` is specified, we attach to `stdin`, `stdout` and `stderr`, there is no ability to control which streams are attached (`docker -a ...`).
|
||||
|
||||
Because we start a Deployment for your container, it will be restarted if you terminate the attached process (e.g. `ctrl-c`), this is different than `docker run -it`.
|
||||
Because we start a Deployment for your container, it will be restarted if you terminate the attached process (e.g. `ctrl-c`), this is different from `docker run -it`.
|
||||
To destroy the Deployment (and its pods) you need to run `kubectl delete deployment <name>`
|
||||
|
||||
#### docker ps
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: JSONpath Support
|
||||
title: JSONPath Support
|
||||
---
|
||||
|
||||
JSONPath template is composed of JSONPath expressions enclosed by {}.
|
||||
|
||||
@@ -23,11 +23,11 @@ If you need stable output in a script, you should:
|
||||
|
||||
In order for `kubectl run` to satisfy infrastructure as code:
|
||||
|
||||
* Always tag your image with a version-specific tag and don't move that tag to a new version. For example, use `:v1234`, `v1.2.3`, `r03062016-1-4`, rather than `:latest` (see [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information.)
|
||||
* If the image is lightly parameterized, capture the parameters in a checked-in script, or at least use `--record`, to annotate the created objects with the command line.
|
||||
* Always tag your image with a version-specific tag and don't move that tag to a new version. For example, use `:v1234`, `v1.2.3`, `r03062016-1-4`, rather than `:latest` (see [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information).
|
||||
* If the image is lightly parameterized, capture the parameters in a checked-in script, or at least use `--record`to annotate the created objects with the command line.
|
||||
* If the image is heavily parameterized, definitely check in the script.
|
||||
* If features are needed that are not expressible via `kubectl run` flags, switch to configuration files checked into source control.
|
||||
* Pin to a specific [generator](#generators) version, such as `kubectl run --generator=deployment/v1beta1`
|
||||
* Pin to a specific [generator](#generators) version, such as `kubectl run --generator=deployment/v1beta1`.
|
||||
|
||||
#### Generators
|
||||
|
||||
|
||||
Reference in New Issue
Block a user