Adding OWNERS for docs.
This commit is contained in:
foxish
@@ -0,0 +1,4 @@
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- mikedanese
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- erictune
|
||||
- lavalamp
|
||||
|
||||
---
|
||||
|
||||
This document describes how access to the Kubernetes API is controlled.
|
||||
|
||||
@@ -1,4 +1,12 @@
|
||||
---
|
||||
assignees:
|
||||
- bprashanth
|
||||
- davidopp
|
||||
- derekwaynecarr
|
||||
- erictune
|
||||
- janetkuo
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- erictune
|
||||
- lavalamp
|
||||
- yifan-gu
|
||||
|
||||
---
|
||||
|
||||
Kubernetes uses client certificates, tokens, or http basic auth to authenticate users for API calls.
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- erictune
|
||||
- lavalamp
|
||||
|
||||
---
|
||||
|
||||
In Kubernetes, authorization happens as a separate step from authentication.
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- lavalamp
|
||||
|
||||
---
|
||||
|
||||
This document outlines the various binary components that need to run to
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- lavalamp
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
|
||||
---
|
||||
|
||||
This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- erictune
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- ArtfulCoder
|
||||
- davidopp
|
||||
- lavalamp
|
||||
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- lavalamp
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
assignees:
|
||||
- mml
|
||||
- nikhiljindal
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- mml
|
||||
- nikhiljindal
|
||||
|
||||
---
|
||||
This guide explains how to set up cluster federation that lets us control multiple Kubernetes clusters.
|
||||
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- dalanlan
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
assignees:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
---
|
||||
assignees:
|
||||
- mwhahaha
|
||||
- stp-ip
|
||||
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
|
||||
---
|
||||
|
||||
The cluster admin guide is for anyone creating or administering a Kubernetes cluster.
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bgrant0607
|
||||
- nikhiljindal
|
||||
|
||||
---
|
||||
|
||||
## kube-apiserver
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- bprashanth
|
||||
- mqliang
|
||||
|
||||
---
|
||||
|
||||
## kube-controller-manager
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
## kube-proxy
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
## kube-scheduler
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- bprashanth
|
||||
- derekwaynecarr
|
||||
- mikedanese
|
||||
|
||||
---
|
||||
|
||||
## kubelet
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
---
|
||||
---
|
||||
---
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
By default, pods run with unbounded CPU and memory limits. This means that any pod in the
|
||||
system will be able to consume as much CPU and memory on the node that executes the pod.
|
||||
@@ -40,32 +44,32 @@ This example will work in a custom namespace to demonstrate the concepts involve
|
||||
|
||||
Let's create a new namespace called limit-example:
|
||||
|
||||
```shell
|
||||
$ kubectl create namespace limit-example
|
||||
namespace "limit-example" created
|
||||
```
|
||||
|
||||
Note that `kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl create namespace limit-example
|
||||
namespace "limit-example" created
|
||||
```
|
||||
|
||||
Note that `kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands:
|
||||
|
||||
```shell
|
||||
$ kubectl get namespaces
|
||||
NAME STATUS AGE
|
||||
default Active 51s
|
||||
limit-example Active 45s
|
||||
```
|
||||
|
||||
NAME STATUS AGE
|
||||
default Active 51s
|
||||
limit-example Active 45s
|
||||
```
|
||||
|
||||
## Step 2: Apply a limit to the namespace
|
||||
|
||||
Let's create a simple limit in our namespace.
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl create -f docs/admin/limitrange/limits.yaml --namespace=limit-example
|
||||
limitrange "mylimits" created
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
Let's describe the limits that we have imposed in our namespace.
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl describe limits mylimits --namespace=limit-example
|
||||
Name: mylimits
|
||||
Namespace: limit-example
|
||||
@@ -75,8 +79,8 @@ Pod cpu 200m 2 - -
|
||||
Pod memory 6Mi 1Gi - - -
|
||||
Container cpu 100m 2 200m 300m -
|
||||
Container memory 3Mi 1Gi 100Mi 200Mi -
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
In this scenario, we have said the following:
|
||||
|
||||
1. If a max constraint is specified for a resource (2 CPU and 1Gi memory in this case), then a limit
|
||||
@@ -103,108 +107,108 @@ of creation explaining why.
|
||||
Let's first spin up a [Deployment](/docs/user-guide/deployments) that creates a single container Pod to demonstrate
|
||||
how default values are applied to each pod.
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl run nginx --image=nginx --replicas=1 --namespace=limit-example
|
||||
deployment "nginx" created
|
||||
```
|
||||
|
||||
Note that `kubectl run` creates a Deployment named "nginx" on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
|
||||
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/kubectl_run/) for more details.
|
||||
The Deployment manages 1 replica of single container Pod. Let's take a look at the Pod it manages. First, find the name of the Pod:
|
||||
|
||||
```shell
|
||||
```
|
||||
|
||||
Note that `kubectl run` creates a Deployment named "nginx" on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
|
||||
If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/user-guide/kubectl/kubectl_run/) for more details.
|
||||
The Deployment manages 1 replica of single container Pod. Let's take a look at the Pod it manages. First, find the name of the Pod:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods --namespace=limit-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-2040093540-s8vzu 1/1 Running 0 11s
|
||||
```
|
||||
|
||||
Let's print this Pod with yaml output format (using `-o yaml` flag), and then `grep` the `resources` field. Note that your pod name will be different.
|
||||
|
||||
``` shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-2040093540-s8vzu 1/1 Running 0 11s
|
||||
```
|
||||
|
||||
Let's print this Pod with yaml output format (using `-o yaml` flag), and then `grep` the `resources` field. Note that your pod name will be different.
|
||||
|
||||
``` shell
|
||||
$ kubectl get pods nginx-2040093540-s8vzu --namespace=limit-example -o yaml | grep resources -C 8
|
||||
resourceVersion: "57"
|
||||
selfLink: /api/v1/namespaces/limit-example/pods/nginx-2040093540-ivimu
|
||||
uid: 67b20741-f53b-11e5-b066-64510658e388
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: nginx
|
||||
resources:
|
||||
limits:
|
||||
cpu: 300m
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 200m
|
||||
memory: 100Mi
|
||||
terminationMessagePath: /dev/termination-log
|
||||
volumeMounts:
|
||||
```
|
||||
|
||||
resourceVersion: "57"
|
||||
selfLink: /api/v1/namespaces/limit-example/pods/nginx-2040093540-ivimu
|
||||
uid: 67b20741-f53b-11e5-b066-64510658e388
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: nginx
|
||||
resources:
|
||||
limits:
|
||||
cpu: 300m
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 200m
|
||||
memory: 100Mi
|
||||
terminationMessagePath: /dev/termination-log
|
||||
volumeMounts:
|
||||
```
|
||||
|
||||
Note that our nginx container has picked up the namespace default cpu and memory resource *limits* and *requests*.
|
||||
|
||||
Let's create a pod that exceeds our allowed limits by having it have a container that requests 3 cpu cores.
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl create -f docs/admin/limitrange/invalid-pod.yaml --namespace=limit-example
|
||||
Error from server: error when creating "docs/admin/limitrange/invalid-pod.yaml": Pod "invalid-pod" is forbidden: [Maximum cpu usage per Pod is 2, but limit is 3., Maximum cpu usage per Container is 2, but limit is 3.]
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
Let's create a pod that falls within the allowed limit boundaries.
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl create -f docs/admin/limitrange/valid-pod.yaml --namespace=limit-example
|
||||
pod "valid-pod" created
|
||||
```
|
||||
|
||||
Now look at the Pod's resources field:
|
||||
|
||||
```shell
|
||||
```
|
||||
|
||||
Now look at the Pod's resources field:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods valid-pod --namespace=limit-example -o yaml | grep -C 6 resources
|
||||
uid: 3b1bfd7a-f53c-11e5-b066-64510658e388
|
||||
spec:
|
||||
containers:
|
||||
- image: gcr.io/google_containers/serve_hostname
|
||||
imagePullPolicy: Always
|
||||
name: kubernetes-serve-hostname
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
memory: 512Mi
|
||||
requests:
|
||||
cpu: "1"
|
||||
memory: 512Mi
|
||||
```
|
||||
|
||||
uid: 3b1bfd7a-f53c-11e5-b066-64510658e388
|
||||
spec:
|
||||
containers:
|
||||
- image: gcr.io/google_containers/serve_hostname
|
||||
imagePullPolicy: Always
|
||||
name: kubernetes-serve-hostname
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
memory: 512Mi
|
||||
requests:
|
||||
cpu: "1"
|
||||
memory: 512Mi
|
||||
```
|
||||
|
||||
Note that this pod specifies explicit resource *limits* and *requests* so it did not pick up the namespace
|
||||
default values.
|
||||
|
||||
Note: The *limits* for CPU resource are enforced in the default Kubernetes setup on the physical node
|
||||
that runs the container unless the administrator deploys the kubelet with the folllowing flag:
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubelet --help
|
||||
Usage of kubelet
|
||||
....
|
||||
--cpu-cfs-quota[=true]: Enable CPU CFS quota enforcement for containers that specify CPU limits
|
||||
$ kubelet --cpu-cfs-quota=false ...
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Step 4: Cleanup
|
||||
|
||||
To remove the resources used by this example, you can just delete the limit-example namespace.
|
||||
|
||||
```shell
|
||||
```shell
|
||||
$ kubectl delete namespace limit-example
|
||||
namespace "limit-example" deleted
|
||||
$ kubectl get namespaces
|
||||
NAME STATUS AGE
|
||||
default Active 12m
|
||||
```
|
||||
|
||||
NAME STATUS AGE
|
||||
default Active 12m
|
||||
```
|
||||
|
||||
## Summary
|
||||
|
||||
Cluster operators that want to restrict the amount of resources a single container or pod may consume
|
||||
are able to define allowable ranges per Kubernetes namespace. In the absence of any explicit assignments,
|
||||
the Kubernetes system is able to apply default resource *limits* and *requests* if desired in order to
|
||||
constrain the amount of resource a pod consumes on a node.
|
||||
constrain the amount of resource a pod consumes on a node.
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- dchen1107
|
||||
- laushinka
|
||||
- roberthbailey
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
|
||||
---
|
||||
|
||||
You may want to set up multiple Kubernetes clusters, both to
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
- madhusudancs
|
||||
|
||||
---
|
||||
|
||||
Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/).
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
assignees:
|
||||
- davidopp
|
||||
- madhusudancs
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- jlowdermilk
|
||||
- justinsb
|
||||
- quinton-hoole
|
||||
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
A Namespace is a mechanism to partition resources created by users into
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
Kubernetes _namespaces_ help different projects, teams, or customers to share a Kubernetes cluster.
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- dcbw
|
||||
- freehan
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- lavalamp
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
Kubernetes approaches networking somewhat differently than Docker does by
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- Random-Liu
|
||||
- dchen1107
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- caesarxuchao
|
||||
- dchen1107
|
||||
- lavalamp
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- vishh
|
||||
- timstclair
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- lavalamp
|
||||
- thockin
|
||||
|
||||
---
|
||||
|
||||
This document describes how OpenVSwitch is used to setup networking between pods across nodes.
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
|
||||
---
|
||||
|
||||
When several users or teams share a cluster with a fixed number of nodes,
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
---
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
|
||||
---
|
||||
|
||||
This example demonstrates a typical setup to control for resource usage in a namespace.
|
||||
|
||||
+19
-15
@@ -1,5 +1,9 @@
|
||||
---
|
||||
---
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
|
||||
---
|
||||
|
||||
The Kubernetes cluster can be configured using Salt.
|
||||
|
||||
@@ -13,11 +17,11 @@ The **salt-minion** service runs on the kubernetes-master and each kubernetes-no
|
||||
|
||||
Each salt-minion service is configured to interact with the **salt-master** service hosted on the kubernetes-master via the **master.conf** file [(except on GCE)](#standalone-salt-configuration-on-gce).
|
||||
|
||||
```shell
|
||||
```shell
|
||||
[root@kubernetes-master] $ cat /etc/salt/minion.d/master.conf
|
||||
master: kubernetes-master
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
The salt-master is contacted by each salt-minion and depending upon the machine information presented, the salt-master will provision the machine as either a kubernetes-master or kubernetes-node with all the required capabilities needed to run Kubernetes.
|
||||
|
||||
If you are running the Vagrant based environment, the **salt-api** service is running on the kubernetes-master. It is configured to enable the vagrant user to introspect the salt cluster in order to find out about machines in the Vagrant environment via a REST API.
|
||||
@@ -34,27 +38,27 @@ All remaining sections that refer to master/minion setups should be ignored for
|
||||
|
||||
Security is not enabled on the salt-master, and the salt-master is configured to auto-accept incoming requests from minions. It is not recommended to use this security configuration in production environments without deeper study. (In some environments this isn't as bad as it might sound if the salt master port isn't externally accessible and you trust everyone on your network.)
|
||||
|
||||
```shell
|
||||
```shell
|
||||
[root@kubernetes-master] $ cat /etc/salt/master.d/auto-accept.conf
|
||||
open_mode: True
|
||||
auto_accept: True
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Salt minion configuration
|
||||
|
||||
Each minion in the salt cluster has an associated configuration that instructs the salt-master how to provision the required resources on the machine.
|
||||
|
||||
An example file is presented below using the Vagrant based environment.
|
||||
|
||||
```shell
|
||||
```shell
|
||||
[root@kubernetes-master] $ cat /etc/salt/minion.d/grains.conf
|
||||
grains:
|
||||
etcd_servers: $MASTER_IP
|
||||
cloud: vagrant
|
||||
roles:
|
||||
- kubernetes-master
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
Each hosting environment has a slightly different grains.conf file that is used to build conditional logic where required in the Salt files.
|
||||
|
||||
The following enumerates the set of defined key/value pairs that are supported today. If you add new ones, please make sure to update this list.
|
||||
@@ -77,16 +81,16 @@ These keys may be leveraged by the Salt sls files to branch behavior.
|
||||
|
||||
In addition, a cluster may be running a Debian based operating system or Red Hat based operating system (Centos, Fedora, RHEL, etc.). As a result, it's important to sometimes distinguish behavior based on operating system using if branches like the following.
|
||||
|
||||
```liquid
|
||||
```liquid
|
||||
{% raw %}
|
||||
{% if grains['os_family'] == 'RedHat' %}
|
||||
// something specific to a RedHat environment (Centos, Fedora, RHEL) where you may use yum, systemd, etc.
|
||||
{% else %}
|
||||
// something specific to Debian environment (apt-get, initd)
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
{% endraw %}
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. When configuring default arguments for processes, it's best to avoid the use of EnvironmentFiles (Systemd in Red Hat environments) or init.d files (Debian distributions) to hold default values that should be common across operating system environments. This helps keep our Salt template files easy to understand for editors who may not be familiar with the particulars of each distribution.
|
||||
|
||||
@@ -1,4 +1,10 @@
|
||||
---
|
||||
assignees:
|
||||
- bprashanth
|
||||
- davidopp
|
||||
- lavalamp
|
||||
- liggitt
|
||||
|
||||
---
|
||||
|
||||
*This is a Cluster Administrator guide to service accounts. It assumes knowledge of
|
||||
|
||||
@@ -1,4 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- jsafrane
|
||||
|
||||
---
|
||||
|
||||
**If you are running clustered Kubernetes and are using static pods to run a pod on every node, you should probably be using a [DaemonSet](/docs/admin/daemons/)!**
|
||||
|
||||
Reference in New Issue
Block a user