Merge branch 'master' into linkify-github-issue
This commit is contained in:
devin-donnelly
@@ -3,7 +3,7 @@ assignees:
|
||||
- bgrant0607
|
||||
- erictune
|
||||
- lavalamp
|
||||
|
||||
title: Overview
|
||||
---
|
||||
|
||||
This document describes how access to the Kubernetes API is controlled.
|
||||
@@ -148,7 +148,7 @@ By default the Kubernetes APIserver serves HTTP on 2 ports:
|
||||
- default IP is first non-localhost network interface, change with `--bind-address` flag.
|
||||
- request handled by authentication and authorization modules.
|
||||
- request handled by admission control module(s).
|
||||
- authentication and authoriation modules run.
|
||||
- authentication and authorisation modules run.
|
||||
|
||||
When the cluster is created by `kube-up.sh`, on Google Compute Engine (GCE),
|
||||
and on several other cloud providers, the API server serves on port 443. On
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
---
|
||||
title: Installing Addons
|
||||
---
|
||||
|
||||
## Overview
|
||||
@@ -11,7 +12,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
|
||||
|
||||
## Networking and Network Policy
|
||||
|
||||
* [Calico](http://docs.projectcalico.org/v1.6/getting-started/kubernetes/installation/hosted/) is a secure L3 networking and network policy provider.
|
||||
* [Calico](http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/) is a secure L3 networking and network policy provider.
|
||||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install/kubeadm) unites Flannel and Calico, providing networking and network policy.
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is a overlay network provider that can be used with Kubernetes.
|
||||
* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/user-guide/networkpolicies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
|
||||
@@ -6,7 +6,7 @@ assignees:
|
||||
- erictune
|
||||
- janetkuo
|
||||
- thockin
|
||||
|
||||
title: Using Admission Controllers
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- stclair
|
||||
|
||||
title: AppArmor
|
||||
---
|
||||
|
||||
AppArmor is a Linux kernel enhancement that can reduce the potential attack surface of an
|
||||
|
||||
@@ -5,8 +5,9 @@ assignees:
|
||||
- ericchiang
|
||||
- deads2k
|
||||
- liggitt
|
||||
|
||||
title: Authenticating
|
||||
---
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
@@ -30,7 +31,7 @@ to talk to the Kubernetes API.
|
||||
API requests are tied to either a normal user or a service account, or are treated
|
||||
as anonymous requests. This means every process inside or outside the cluster, from
|
||||
a human user typing `kubectl` on a workstation, to `kubelets` on nodes, to members
|
||||
of the control plane, must authenticate when making requests to the the API server,
|
||||
of the control plane, must authenticate when making requests to the API server,
|
||||
or be treated as an anonymous user.
|
||||
|
||||
## Authentication strategies
|
||||
|
||||
@@ -4,7 +4,7 @@ assignees:
|
||||
- lavalamp
|
||||
- deads2k
|
||||
- liggitt
|
||||
|
||||
title: Using Authorization Plugins
|
||||
---
|
||||
|
||||
In Kubernetes, authorization happens as a separate step from authentication.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- lavalamp
|
||||
|
||||
title: Kubernetes Components
|
||||
---
|
||||
|
||||
This document outlines the various binary components that need to run to
|
||||
|
||||
@@ -1,11 +1,10 @@
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
|
||||
---
|
||||
|
||||
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
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:
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
assignees:
|
||||
- lavalamp
|
||||
- thockin
|
||||
|
||||
title: Cluster Management Guide
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
|
||||
title: Troubleshooting Clusters
|
||||
---
|
||||
|
||||
This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
assignees:
|
||||
- erictune
|
||||
|
||||
title: Daemon Sets
|
||||
---
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## What is a _Daemon Set_?
|
||||
## What is a Daemon Set?
|
||||
|
||||
A _Daemon Set_ ensures that all (or some) nodes run a copy of a pod. As nodes are added to the
|
||||
cluster, pods are added to them. As nodes are removed from the cluster, those pods are garbage
|
||||
@@ -74,7 +74,7 @@ a node for testing.
|
||||
|
||||
If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
|
||||
create pods on nodes which match that [node
|
||||
selector](https://github.com/kubernetes/kubernetes.github.io/tree/{{page.docsbranch}}/docs/user-guide/node-selection).
|
||||
selector](/docs/user-guide/node-selection/).
|
||||
If you specify a `scheduler.alpha.kubernetes.io/affinity` annotation in `.spec.template.metadata.annotations`,
|
||||
then DaemonSet controller will create pods on nodes which match that [node affinity](../../user-guide/node-selection/#alpha-feature-in-kubernetes-v12-node-affinity).
|
||||
|
||||
@@ -99,7 +99,7 @@ Some possible patterns for communicating with pods in a DaemonSet are:
|
||||
- **Push**: Pods in the Daemon Set are configured to send updates to another service, such
|
||||
as a stats database. They do not have clients.
|
||||
- **NodeIP and Known Port**: Pods in the Daemon Set use a `hostPort`, so that the pods are reachable
|
||||
via the node IPs. Clients knows the the list of nodes ips somehow, and know the port by convention.
|
||||
via the node IPs. Clients knows the list of nodes ips somehow, and know the port by convention.
|
||||
- **DNS**: Create a [headless service](/docs/user-guide/services/#headless-services) with the same pod selector,
|
||||
and then discover DaemonSets using the `endpoints` resource or retrieve multiple A records from
|
||||
DNS.
|
||||
|
||||
+12
-12
@@ -3,7 +3,7 @@ assignees:
|
||||
- ArtfulCoder
|
||||
- davidopp
|
||||
- lavalamp
|
||||
|
||||
title: Using DNS Pods and Services
|
||||
---
|
||||
|
||||
## Introduction
|
||||
@@ -70,7 +70,7 @@ is no longer supported.
|
||||
|
||||
When enabled, pods are assigned a DNS A record in the form of `pod-ip-address.my-namespace.pod.cluster.local`.
|
||||
|
||||
For example, a pod with ip `1.2.3.4` in the namespace `default` with a dns name of `cluster.local` would have an entry: `1-2-3-4.default.pod.cluster.local`.
|
||||
For example, a pod with ip `1.2.3.4` in the namespace `default` with a DNS name of `cluster.local` would have an entry: `1-2-3-4.default.pod.cluster.local`.
|
||||
|
||||
#### A Records and hostname based on Pod's hostname and subdomain fields
|
||||
|
||||
@@ -171,7 +171,7 @@ busybox 1/1 Running 0 <some-time>
|
||||
Once that pod is running, you can exec nslookup in that environment:
|
||||
|
||||
```
|
||||
kubectl exec busybox -- nslookup kubernetes.default
|
||||
kubectl exec -ti busybox -- nslookup kubernetes.default
|
||||
```
|
||||
|
||||
You should see something like:
|
||||
@@ -194,10 +194,10 @@ If the nslookup command fails, check the following:
|
||||
Take a look inside the resolv.conf file. (See "Inheriting DNS from the node" and "Known issues" below for more information)
|
||||
|
||||
```
|
||||
cat /etc/resolv.conf
|
||||
kubectl exec busybox cat /etc/resolv.conf
|
||||
```
|
||||
|
||||
Verify that the search path and name server are set up like the following (note that seach path may vary for different cloud providers):
|
||||
Verify that the search path and name server are set up like the following (note that search path may vary for different cloud providers):
|
||||
|
||||
```
|
||||
search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
|
||||
@@ -210,7 +210,7 @@ options ndots:5
|
||||
Errors such as the following indicate a problem with the kube-dns add-on or associated Services:
|
||||
|
||||
```
|
||||
$ kubectl exec busybox -- nslookup kubernetes.default
|
||||
$ kubectl exec -ti busybox -- nslookup kubernetes.default
|
||||
Server: 10.0.0.10
|
||||
Address 1: 10.0.0.10
|
||||
|
||||
@@ -220,7 +220,7 @@ nslookup: can't resolve 'kubernetes.default'
|
||||
or
|
||||
|
||||
```
|
||||
$ kubectl exec busybox -- nslookup kubernetes.default
|
||||
$ kubectl exec -ti busybox -- nslookup kubernetes.default
|
||||
Server: 10.0.0.10
|
||||
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
|
||||
|
||||
@@ -244,21 +244,21 @@ kube-dns-v19-ezo1y 3/3 Running 0
|
||||
...
|
||||
```
|
||||
|
||||
If you see that no pod is running or that the pod has failed/completed, the dns add-on may not be deployed by default in your current environment and you will have to deploy it manually.
|
||||
If you see that no pod is running or that the pod has failed/completed, the DNS add-on may not be deployed by default in your current environment and you will have to deploy it manually.
|
||||
|
||||
#### Check for Errors in the DNS pod
|
||||
|
||||
Use `kubectl logs` command to see logs for the DNS daemons.
|
||||
|
||||
```
|
||||
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
|
||||
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kube-dns
|
||||
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
|
||||
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c healthz
|
||||
```
|
||||
|
||||
See if there is any suspicious log. W, E, F letter at the beginning represent Warning, Error and Failure. Please search for entries that have these as the logging level and use [kubernetes issues](https://github.com/kubernetes/kubernetes/issues) to report unexpected errors.
|
||||
|
||||
#### Is dns service up?
|
||||
#### Is DNS service up?
|
||||
|
||||
Verify that the DNS service is up by using the `kubectl get service` command.
|
||||
|
||||
@@ -277,7 +277,7 @@ kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 1h
|
||||
|
||||
If you have created the service or in the case it should be created by default but it does not appear, see this [debugging services page](http://kubernetes.io/docs/user-guide/debugging-services/) for more information.
|
||||
|
||||
#### Are dns endpoints exposed?
|
||||
#### Are DNS endpoints exposed?
|
||||
|
||||
You can verify that dns endpoints are exposed by using the `kubectl get endpoints` command.
|
||||
|
||||
@@ -348,7 +348,7 @@ some of those settings will be lost. As a partial workaround, the node can run
|
||||
`dnsmasq` which will provide more `nameserver` entries, but not more `search`
|
||||
entries. You can also use kubelet's `--resolv-conf` flag.
|
||||
|
||||
If you are using Alpine version 3.3 or earlier as your base image, dns may not
|
||||
If you are using Alpine version 3.3 or earlier as your base image, DNS may not
|
||||
work properly owing to a known issue with Alpine. Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
|
||||
for more information.
|
||||
|
||||
|
||||
+1
-2
@@ -1,10 +1,9 @@
|
||||
---
|
||||
assignees:
|
||||
- lavalamp
|
||||
|
||||
title: Configuring Kubernetes Use of etcd
|
||||
---
|
||||
|
||||
|
||||
[etcd](https://coreos.com/etcd/docs/2.2.1/) is a highly-available key value
|
||||
store which Kubernetes uses for persistent storage of all of its REST API
|
||||
objects.
|
||||
|
||||
@@ -1,5 +1,8 @@
|
||||
---
|
||||
title: federation-apiserver
|
||||
notitle: true
|
||||
---
|
||||
|
||||
## federation-apiserver
|
||||
|
||||
|
||||
|
||||
@@ -1,5 +1,8 @@
|
||||
---
|
||||
title: federation-controller-mananger
|
||||
notitle: true
|
||||
---
|
||||
|
||||
## federation-controller-manager
|
||||
|
||||
|
||||
|
||||
@@ -3,8 +3,9 @@ assignees:
|
||||
- madhusudancs
|
||||
- mml
|
||||
- nikhiljindal
|
||||
|
||||
title: Using `federation-up` and `deploy.sh`
|
||||
---
|
||||
|
||||
This guide explains how to set up cluster federation that lets us control multiple Kubernetes clusters.
|
||||
|
||||
|
||||
|
||||
@@ -3,6 +3,10 @@ assignees:
|
||||
- madhusudancs
|
||||
|
||||
---
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
Kubernetes version 1.5 includes a new command line tool called
|
||||
`kubefed` to help you administrate your federated clusters.
|
||||
`kubefed` helps you to deploy a new Kubernetes cluster federation
|
||||
@@ -14,11 +18,6 @@ using `kubefed`.
|
||||
|
||||
> Note: `kubefed` is an alpha feature in Kubernetes 1.5.
|
||||
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
This guide assumes that you have a running Kubernetes cluster. Please
|
||||
@@ -61,8 +60,8 @@ The output should contain an entry corresponding to your host cluster,
|
||||
similar to the following:
|
||||
|
||||
```
|
||||
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
|
||||
gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1
|
||||
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
|
||||
gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1 gke_myproject_asia-east1-b_gce-asia-east1
|
||||
```
|
||||
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
|
||||
title: Configuring kubelet Garbage Collection
|
||||
---
|
||||
|
||||
* TOC
|
||||
@@ -17,7 +17,7 @@ kubernetes manages lifecycle of all images through imageManager, with the cooper
|
||||
of cadvisor.
|
||||
|
||||
The policy for garbage collecting images takes two factors into consideration:
|
||||
`HighThresholdPercent` and `LowThresholdPercent`. Disk usage above the the high threshold
|
||||
`HighThresholdPercent` and `LowThresholdPercent`. Disk usage above the high threshold
|
||||
will trigger garbage collection. The garbage collection will delete least recently used images until the low
|
||||
threshold has been met.
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
title: Building High-Availability Clusters
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
This document describes how to build a high-availability (HA) Kubernetes cluster. This is a fairly advanced topic.
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
assignees:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
|
||||
title: Admin Guide
|
||||
---
|
||||
|
||||
The cluster admin guide is for anyone creating or administering a Kubernetes cluster.
|
||||
|
||||
@@ -1,5 +1,8 @@
|
||||
---
|
||||
title: kube-apiserver
|
||||
notitle: true
|
||||
---
|
||||
|
||||
## kube-apiserver
|
||||
|
||||
|
||||
|
||||
@@ -1,5 +1,8 @@
|
||||
---
|
||||
title: kube-controller-manager
|
||||
notitle: true
|
||||
---
|
||||
|
||||
## kube-controller-manager
|
||||
|
||||
|
||||
@@ -42,7 +45,7 @@ kube-controller-manager
|
||||
--concurrent_rc_syncs int32 The number of replication controllers that are allowed to sync concurrently. Larger number = more responsive replica management, but more CPU (and network) load (default 5)
|
||||
--configure-cloud-routes Should CIDRs allocated by allocate-node-cidrs be configured on the cloud provider. (default true)
|
||||
--controller-start-interval duration Interval between starting controller managers.
|
||||
--daemonset-lookup-cache-size int32 The the size of lookup cache for daemonsets. Larger number = more responsive daemonsets, but more MEM load. (default 1024)
|
||||
--daemonset-lookup-cache-size int32 The size of lookup cache for daemonsets. Larger number = more responsive daemonsets, but more MEM load. (default 1024)
|
||||
--deployment-controller-sync-period duration Period for syncing the deployments. (default 30s)
|
||||
--enable-dynamic-provisioning Enable dynamic provisioning for environments that support it. (default true)
|
||||
--enable-garbage-collector Enables the generic garbage collector. MUST be synced with the corresponding flag of the kube-apiserver. (default true)
|
||||
@@ -86,8 +89,8 @@ StreamingProxyRedirects=true|false (ALPHA - default=false)
|
||||
--pv-recycler-pod-template-filepath-nfs string The file path to a pod definition used as a template for NFS persistent volume recycling
|
||||
--pv-recycler-timeout-increment-hostpath int32 the increment of time added per Gi to ActiveDeadlineSeconds for a HostPath scrubber pod. This is for development and testing only and will not work in a multi-node cluster. (default 30)
|
||||
--pvclaimbinder-sync-period duration The period for syncing persistent volumes and persistent volume claims (default 15s)
|
||||
--replicaset-lookup-cache-size int32 The the size of lookup cache for replicatsets. Larger number = more responsive replica management, but more MEM load. (default 4096)
|
||||
--replication-controller-lookup-cache-size int32 The the size of lookup cache for replication controllers. Larger number = more responsive replica management, but more MEM load. (default 4096)
|
||||
--replicaset-lookup-cache-size int32 The size of lookup cache for replicatsets. Larger number = more responsive replica management, but more MEM load. (default 4096)
|
||||
--replication-controller-lookup-cache-size int32 The size of lookup cache for replication controllers. Larger number = more responsive replica management, but more MEM load. (default 4096)
|
||||
--resource-quota-sync-period duration The period for syncing quota usage status in the system (default 5m0s)
|
||||
--root-ca-file string If set, this root certificate authority will be included in service account's token secret. This must be a valid PEM-encoded CA bundle.
|
||||
--route-reconciliation-period duration The period for reconciling routes created for Nodes by cloud provider. (default 10s)
|
||||
|
||||
@@ -1,5 +1,8 @@
|
||||
---
|
||||
title: kube-proxy
|
||||
notitle: true
|
||||
---
|
||||
|
||||
## kube-proxy
|
||||
|
||||
|
||||
|
||||
@@ -1,5 +1,8 @@
|
||||
---
|
||||
title: kube-scheduler
|
||||
notitle: true
|
||||
---
|
||||
|
||||
## kube-scheduler
|
||||
|
||||
|
||||
|
||||
+64
-38
@@ -4,10 +4,9 @@ assignees:
|
||||
- luxas
|
||||
- errordeveloper
|
||||
- jbeda
|
||||
|
||||
title: kubeadm reference
|
||||
---
|
||||
|
||||
|
||||
This document provides information on how to use kubeadm's advanced options.
|
||||
|
||||
Running `kubeadm init` bootstraps a Kubernetes cluster. This consists of the
|
||||
@@ -82,7 +81,7 @@ of the box. You can specify a cloud provider using `--cloud-provider`.
|
||||
Valid values are the ones supported by `controller-manager`, namely `"aws"`,
|
||||
`"azure"`, `"cloudstack"`, `"gce"`, `"mesos"`, `"openstack"`, `"ovirt"`,
|
||||
`"rackspace"`, `"vsphere"`. In order to provide additional configuration for
|
||||
the cloud provider, you should create a `/etc/kubernetes/cloud-config.json`
|
||||
the cloud provider, you should create a `/etc/kubernetes/cloud-config`
|
||||
file manually, before running `kubeadm init`. `kubeadm` automatically
|
||||
picks those settings up and ensures other nodes are configured correctly.
|
||||
You must also set the `--cloud-provider` and `--cloud-config` parameters
|
||||
@@ -141,10 +140,10 @@ By default, `kubeadm init` automatically generates the token used to initialise
|
||||
each new node. If you would like to manually specify this token, you can use the
|
||||
`--token` flag. The token must be of the format `<6 character string>.<16 character string>`.
|
||||
|
||||
- `--use-kubernetes-version` (default 'v1.4.4') the kubernetes version to initialise
|
||||
- `--use-kubernetes-version` (default 'v1.5.1') the kubernetes version to initialise
|
||||
|
||||
`kubeadm` was originally built for Kubernetes version **v1.4.0**, older versions are not
|
||||
supported. With this flag you can try any future version, e.g. **v1.5.0-beta.1**
|
||||
supported. With this flag you can try any future version, e.g. **v1.6.0-beta.1**
|
||||
whenever it comes out (check [releases page](https://github.com/kubernetes/kubernetes/releases)
|
||||
for a full list of available versions).
|
||||
|
||||
@@ -168,6 +167,59 @@ necessary.
|
||||
By default, when `kubeadm init` runs, a token is generated and revealed in the output.
|
||||
That's the token you should use here.
|
||||
|
||||
|
||||
## Using kubeadm with a configuration file
|
||||
|
||||
WARNING: kubeadm is in alpha and the configuration API syntax will likely change before GA.
|
||||
|
||||
It's possible to configure kubeadm with a configuration file instead of command line flags, and some more advanced features may only be
|
||||
available as configuration file options.
|
||||
|
||||
### Sample Master Configuration
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1alpha1
|
||||
kind: MasterConfiguration
|
||||
api:
|
||||
advertiseAddresses:
|
||||
- <address1|string>
|
||||
- <address2|string>
|
||||
bindPort: <int>
|
||||
externalDNSNames:
|
||||
- <dnsname1|string>
|
||||
- <dnsname2|string>
|
||||
cloudProvider: <string>
|
||||
discovery:
|
||||
bindPort: <int>
|
||||
etcd:
|
||||
endpoints:
|
||||
- <endpoint1|string>
|
||||
- <endpoint2|string>
|
||||
caFile: <path|string>
|
||||
certFile: <path|string>
|
||||
keyFile: <path|string>
|
||||
kubernetesVersion: <string>
|
||||
networking:
|
||||
dnsDomain: <string>
|
||||
serviceSubnet: <cidr>
|
||||
podSubnet: <cidr>
|
||||
secrets:
|
||||
givenToken: <token|string>
|
||||
```
|
||||
|
||||
### Sample Node Configuration
|
||||
|
||||
```yaml
|
||||
apiVersion: kubeadm.k8s.io/v1alpha1
|
||||
kind: NodeConfiguration
|
||||
apiPort: <int>
|
||||
discoveryPort: <int>
|
||||
masterAddresses:
|
||||
- <master1>
|
||||
secrets:
|
||||
givenToken: <token|string>
|
||||
```
|
||||
|
||||
## Automating kubeadm
|
||||
|
||||
Rather than copying the token you obtained from `kubeadm init` to each node, as
|
||||
@@ -175,13 +227,12 @@ in the basic `kubeadm` tutorials, you can parallelize the token distribution for
|
||||
easier automation. To implement this automation, you must know the IP address
|
||||
that the master will have after it is started.
|
||||
|
||||
1. Generate a token. This token must have the form `<6 character string>.<16
|
||||
character string>`
|
||||
1. Generate a token. This token must have the form `<6 character string>.<16 character string>`.
|
||||
|
||||
Here is a simple python one-liner for this:
|
||||
Kubeadm can pre-generate a token for you:
|
||||
|
||||
```
|
||||
python -c 'import random; print "%0x.%0x" % (random.SystemRandom().getrandbits(3*8), random.SystemRandom().getrandbits(8*8))'
|
||||
```console
|
||||
$ kubeadm token generate
|
||||
```
|
||||
|
||||
1. Start both the master node and the worker nodes concurrently with this token. As they come up they should find each other and form the cluster.
|
||||
@@ -191,6 +242,7 @@ Once the cluster is up, you can grab the admin credentials from the master node
|
||||
## Environment variables
|
||||
|
||||
There are some environment variables that modify the way that `kubeadm` works. Most users will have no need to set these.
|
||||
These enviroment variables are a short-term solution, eventually they will be integrated in the kubeadm configuration file.
|
||||
|
||||
| Variable | Default | Description |
|
||||
| --- | --- | --- |
|
||||
@@ -200,36 +252,10 @@ There are some environment variables that modify the way that `kubeadm` works.
|
||||
| `KUBE_HYPERKUBE_IMAGE` | `` | If set, use a single hyperkube image with this name. If not set, individual images per server component will be used. |
|
||||
| `KUBE_DISCOVERY_IMAGE` | `gcr.io/google_containers/kube-discovery-<arch>:1.0` | The bootstrap discovery helper image to use. |
|
||||
| `KUBE_ETCD_IMAGE` | `gcr.io/google_containers/etcd-<arch>:2.2.5` | The etcd container image to use. |
|
||||
| `KUBE_COMPONENT_LOGLEVEL` | `--v=4` | Logging configuration for all Kubernetes components |
|
||||
|
||||
| `KUBE_REPO_PREFIX` | `gcr.io/google_containers` | The image prefix for all images that are used. |
|
||||
|
||||
## Releases and release notes
|
||||
|
||||
If you already have kubeadm installed and want to upgrade, run `apt-get update && apt-get upgrade` or `yum update` to get the latest version of kubeadm.
|
||||
|
||||
- Second release between v1.4 and v1.5: `v1.5.0-alpha.2.421+a6bea3d79b8bba`
|
||||
- Switch to the 10.96.0.0/12 subnet: [#35290](https://github.com/kubernetes/kubernetes/pull/35290)
|
||||
- Fix kubeadm on AWS by including /etc/ssl/certs in the controller-manager [#33681](https://github.com/kubernetes/kubernetes/pull/33681)
|
||||
- The API was refactored and is now componentconfig: [#33728](https://github.com/kubernetes/kubernetes/pull/33728), [#34147](https://github.com/kubernetes/kubernetes/pull/34147) and [#34555](https://github.com/kubernetes/kubernetes/pull/34555)
|
||||
- Allow kubeadm to get config options from a file: [#34501](https://github.com/kubernetes/kubernetes/pull/34501), [#34885](https://github.com/kubernetes/kubernetes/pull/34885) and [#34891](https://github.com/kubernetes/kubernetes/pull/34891)
|
||||
- Implement preflight checks: [#34341](https://github.com/kubernetes/kubernetes/pull/34341) and [#35843](https://github.com/kubernetes/kubernetes/pull/35843)
|
||||
- Using kubernetes v1.4.4 by default: [#34419](https://github.com/kubernetes/kubernetes/pull/34419) and [#35270](https://github.com/kubernetes/kubernetes/pull/35270)
|
||||
- Make api and discovery ports configurable and default to 6443: [#34719](https://github.com/kubernetes/kubernetes/pull/34719)
|
||||
- Implement kubeadm reset: [#34807](https://github.com/kubernetes/kubernetes/pull/34807)
|
||||
- Make kubeadm poll/wait for endpoints instead of directly fail when the master isn't available [#34703](https://github.com/kubernetes/kubernetes/pull/34703) and [#34718](https://github.com/kubernetes/kubernetes/pull/34718)
|
||||
- Allow empty directories in the directory preflight check: [#35632](https://github.com/kubernetes/kubernetes/pull/35632)
|
||||
- Started adding unit tests: [#35231](https://github.com/kubernetes/kubernetes/pull/35231), [#35326](https://github.com/kubernetes/kubernetes/pull/35326) and [#35332](https://github.com/kubernetes/kubernetes/pull/35332)
|
||||
- Various enhancements: [#35075](https://github.com/kubernetes/kubernetes/pull/35075), [#35111](https://github.com/kubernetes/kubernetes/pull/35111), [#35119](https://github.com/kubernetes/kubernetes/pull/35119), [#35124](https://github.com/kubernetes/kubernetes/pull/35124), [#35265](https://github.com/kubernetes/kubernetes/pull/35265) and [#35777](https://github.com/kubernetes/kubernetes/pull/35777)
|
||||
- Bug fixes: [#34352](https://github.com/kubernetes/kubernetes/pull/34352), [#34558](https://github.com/kubernetes/kubernetes/pull/34558), [#34573](https://github.com/kubernetes/kubernetes/pull/34573), [#34834](https://github.com/kubernetes/kubernetes/pull/34834), [#34607](https://github.com/kubernetes/kubernetes/pull/34607), [#34907](https://github.com/kubernetes/kubernetes/pull/34907) and [#35796](https://github.com/kubernetes/kubernetes/pull/35796)
|
||||
- Initial v1.4 release: `v1.5.0-alpha.0.1534+cf7301f16c0363`
|
||||
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
* Some users on RHEL/CentOS 7 have reported issues with traffic being routed incorrectly due to iptables being bypassed. You should ensure `net.bridge.bridge-nf-call-iptables` is set to 1 in your sysctl config, eg.
|
||||
|
||||
```
|
||||
# cat /etc/sysctl.d/k8s.conf
|
||||
net.bridge.bridge-nf-call-ip6tables = 1
|
||||
net.bridge.bridge-nf-call-iptables = 1
|
||||
```
|
||||
Refer to the [CHANGELOG.md](https://github.com/kubernetes/kubeadm/blob/master/CHANGELOG.md) for more information.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- liggitt
|
||||
|
||||
title: Kubelet authentication/authorization
|
||||
---
|
||||
|
||||
* TOC
|
||||
@@ -17,35 +17,40 @@ This document describes how to authenticate and authorize access to the kubelet'
|
||||
## Kubelet authentication
|
||||
|
||||
By default, requests to the kubelet's HTTPS endpoint that are not rejected by other configured
|
||||
authentication methods are treated as anonymous requests, and given a username of `system:anonymous`
|
||||
authentication methods are treated as anonymous requests, and given a username of `system:anonymous`
|
||||
and a group of `system:unauthenticated`.
|
||||
|
||||
To disable anonymous access and send `401 Unauthorized` responses to unauthenticated requests:
|
||||
|
||||
* start the kubelet with the `--anonymous-auth=false` flag
|
||||
|
||||
To enable X509 client certificate authentication to the kubelet's HTTPS endpoint:
|
||||
* start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with
|
||||
|
||||
* start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with
|
||||
* start the apiserver with `--kubelet-client-certificate` and `--kubelet-client-key` flags
|
||||
* see the [apiserver authentication documentation](/docs/admin/authentication/#x509-client-certs) for more details
|
||||
|
||||
To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint:
|
||||
|
||||
* ensure the `authentication.k8s.io/v1beta1` API group is enabled in the API server
|
||||
* start the kubelet with the `--authentication-token-webhook`, `--kubeconfig`, and `--require-kubeconfig` flags
|
||||
* the kubelet calls the `TokenReview` API on the configured API server to determine user information from bearer tokens
|
||||
* the kubelet calls the `TokenReview` API on the configured API server to determine user information from bearer tokens
|
||||
|
||||
## Kubelet authorization
|
||||
|
||||
Any request that is successfully authenticated (including an anonymous request) is then authorized. The default authorization mode is `AlwaysAllow`, which allows all requests.
|
||||
|
||||
There are many possible reasons to subdivide access to the kubelet API:
|
||||
|
||||
* anonymous auth is enabled, but anonymous users' ability to call the kubelet API should be limited
|
||||
* bearer token auth is enabled, but arbitrary API users' (like service accounts) ability to call the kubelet API should be limited
|
||||
* client certificate auth is enabled, but only some of the client certificates signed by the configured CA should be allowed to use the kubelet API
|
||||
|
||||
To subdivide access to the kubelet API, delegate authorization to the API server:
|
||||
|
||||
* ensure the `authorization.k8s.io/v1beta1` API group is enabled in the API server
|
||||
* start the kubelet with the `--authorization-mode=Webhook`, `--kubeconfig`, and `--require-kubeconfig` flags
|
||||
* the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized
|
||||
* the kubelet calls the `SubjectAccessReview` API on the configured API server to determine whether each request is authorized
|
||||
|
||||
The kubelet authorizes API requests using the same [request attributes](/docs/admin/authorization/#request-attributes) approach as the apiserver.
|
||||
|
||||
@@ -63,19 +68,20 @@ The resource and subresource is determined from the incoming request's path:
|
||||
|
||||
Kubelet API | resource | subresource
|
||||
-------------|----------|------------
|
||||
/stats/* | nodes | stats
|
||||
/metrics/* | nodes | metrics
|
||||
/logs/* | nodes | log
|
||||
/spec/* | nodes | spec
|
||||
/stats/\* | nodes | stats
|
||||
/metrics/\* | nodes | metrics
|
||||
/logs/\* | nodes | log
|
||||
/spec/\* | nodes | spec
|
||||
*all others* | nodes | proxy
|
||||
|
||||
The namespace and API group attributes are always an empty string, and
|
||||
The namespace and API group attributes are always an empty string, and
|
||||
the resource name is always the name of the kubelet's `Node` API object.
|
||||
|
||||
When running in this mode, ensure the user identified by the `--kubelet-client-certificate` and `--kubelet-client-key`
|
||||
When running in this mode, ensure the user identified by the `--kubelet-client-certificate` and `--kubelet-client-key`
|
||||
flags passed to the apiserver is authorized for the following attributes:
|
||||
* verb=*, resource=nodes, subresource=proxy
|
||||
* verb=*, resource=nodes, subresource=stats
|
||||
* verb=*, resource=nodes, subresource=log
|
||||
* verb=*, resource=nodes, subresource=spec
|
||||
* verb=*, resource=nodes, subresource=metrics
|
||||
|
||||
* verb=\*, resource=nodes, subresource=proxy
|
||||
* verb=\*, resource=nodes, subresource=stats
|
||||
* verb=\*, resource=nodes, subresource=log
|
||||
* verb=\*, resource=nodes, subresource=spec
|
||||
* verb=\*, resource=nodes, subresource=metrics
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- mikedanese
|
||||
|
||||
title: TLS bootstrapping
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,5 +1,8 @@
|
||||
---
|
||||
title: Overview
|
||||
notitle: true
|
||||
---
|
||||
|
||||
## kubelet
|
||||
|
||||
|
||||
@@ -14,7 +17,7 @@ various mechanisms (primarily through the apiserver) and ensures that the contai
|
||||
described in those PodSpecs are running and healthy. The kubelet doesn't manage
|
||||
containers which were not created by Kubernetes.
|
||||
|
||||
Other than from an PodSpec from the apiserver, there are three ways that a container
|
||||
Other than from a PodSpec from the apiserver, there are three ways that a container
|
||||
manifest can be provided to the Kubelet.
|
||||
|
||||
File: Path passed as a flag on the command line. This file is rechecked every 20
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
|
||||
title: Setting Pod CPU and Memory Limits
|
||||
---
|
||||
|
||||
By default, pods run with unbounded CPU and memory limits. This means that any pod in the
|
||||
|
||||
@@ -3,7 +3,7 @@ assignees:
|
||||
- dchen1107
|
||||
- roberthbailey
|
||||
- liggitt
|
||||
|
||||
title: Master-Node communication
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- davidopp
|
||||
|
||||
title: Using Multiple Clusters
|
||||
---
|
||||
|
||||
You may want to set up multiple Kubernetes clusters, both to
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
assignees:
|
||||
- davidopp
|
||||
- madhusudancs
|
||||
|
||||
title: Configuring Multiple Schedulers
|
||||
---
|
||||
|
||||
Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/).
|
||||
|
||||
@@ -3,7 +3,7 @@ assignees:
|
||||
- jlowdermilk
|
||||
- justinsb
|
||||
- quinton-hoole
|
||||
|
||||
title: Running in Multiple Zones
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
|
||||
title: Sharing a Cluster with Namespaces
|
||||
---
|
||||
|
||||
A Namespace is a mechanism to partition resources created by users into
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
|
||||
title: Namespaces Walkthrough
|
||||
---
|
||||
|
||||
Kubernetes _namespaces_ help different projects, teams, or customers to share a Kubernetes cluster.
|
||||
|
||||
@@ -3,7 +3,7 @@ assignees:
|
||||
- dcbw
|
||||
- freehan
|
||||
- thockin
|
||||
|
||||
title: Network Plugins
|
||||
---
|
||||
|
||||
* TOC
|
||||
@@ -26,13 +26,13 @@ The kubelet has a single default network plugin, and a default network common to
|
||||
|
||||
## Network Plugin Requirements
|
||||
|
||||
Besides providing the [`NetworkPlugin` interface](https://github.com/kubernetes/kubernetes/tree/{{page.version}}.0/pkg/kubelet/network/plugins.go) to configure and clean up pod networking, the plugin may also need specific support for kube-proxy. The iptables proxy obviously depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables. For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly. If the plugin does not use a Linux bridge (but instead something like Open vSwitch or some other mechanism) it should ensure container traffic is appropriately routed for the proxy.
|
||||
Besides providing the [`NetworkPlugin` interface](https://github.com/kubernetes/kubernetes/tree/{{page.version}}/pkg/kubelet/network/plugins.go) to configure and clean up pod networking, the plugin may also need specific support for kube-proxy. The iptables proxy obviously depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables. For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly. If the plugin does not use a Linux bridge (but instead something like Open vSwitch or some other mechanism) it should ensure container traffic is appropriately routed for the proxy.
|
||||
|
||||
By default if no kubelet network plugin is specified, the `noop` plugin is used, which sets `net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like docker with a bridge) work correctly with the iptables proxy.
|
||||
|
||||
### Exec
|
||||
|
||||
Place plugins in `network-plugin-dir/plugin-name/plugin-name`, i.e if you have a bridge plugin and `network-plugin-dir` is `/usr/lib/kubernetes`, you'd place the bridge plugin executable at `/usr/lib/kubernetes/bridge/bridge`. See [this comment](https://github.com/kubernetes/kubernetes/tree/{{page.version}}.0/pkg/kubelet/network/exec/exec.go) for more details.
|
||||
Place plugins in `network-plugin-dir/plugin-name/plugin-name`, i.e if you have a bridge plugin and `network-plugin-dir` is `/usr/lib/kubernetes`, you'd place the bridge plugin executable at `/usr/lib/kubernetes/bridge/bridge`. See [this comment](https://github.com/kubernetes/kubernetes/tree/{{page.version}}/pkg/kubelet/network/exec/exec.go) for more details.
|
||||
|
||||
### CNI
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
assignees:
|
||||
- lavalamp
|
||||
- thockin
|
||||
|
||||
title: Networking in Kubernetes
|
||||
---
|
||||
|
||||
Kubernetes approaches networking somewhat differently than Docker does by
|
||||
@@ -171,7 +171,7 @@ Lars Kellogg-Stedman.
|
||||
|
||||
### Nuage Networks VCS (Virtualized Cloud Services)
|
||||
|
||||
[Nuage](www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
|
||||
[Nuage](http://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
|
||||
|
||||
The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage’s policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform’s real-time analytics engine enables visibility and security monitoring for Kubernetes applications.
|
||||
|
||||
@@ -181,6 +181,14 @@ The Nuage platform uses overlays to provide seamless policy-based networking bet
|
||||
complicated way to build an overlay network. This is endorsed by several of the
|
||||
"Big Shops" for networking.
|
||||
|
||||
### OVN (Open Virtual Networking)
|
||||
|
||||
OVN is an opensource network virtualization solution developed by the
|
||||
Open vSwitch community. It lets one create logical switches, logical routers,
|
||||
stateful ACLs, load-balancers etc to build different virtual networking
|
||||
topologies. The project has a specific Kubernetes plugin and documentation
|
||||
at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).
|
||||
|
||||
### Project Calico
|
||||
|
||||
[Project Calico](http://docs.projectcalico.org/) is an open source container networking provider and network policy engine.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- Random-Liu
|
||||
|
||||
title: Validate Node Setup
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
assignees:
|
||||
- Random-Liu
|
||||
- dchen1107
|
||||
|
||||
title: Monitoring Node Health
|
||||
---
|
||||
|
||||
* TOC
|
||||
|
||||
+2
-2
@@ -3,7 +3,7 @@ assignees:
|
||||
- caesarxuchao
|
||||
- dchen1107
|
||||
- lavalamp
|
||||
|
||||
title: Nodes
|
||||
---
|
||||
|
||||
* TOC
|
||||
@@ -186,7 +186,7 @@ Modifications include setting labels on the node and marking it unschedulable.
|
||||
Labels on nodes can be used in conjunction with node selectors on pods to control scheduling,
|
||||
e.g. to constrain a pod to only be eligible to run on a subset of the nodes.
|
||||
|
||||
Marking a node as unscheduleable will prevent new pods from being scheduled to that
|
||||
Marking a node as unschedulable will prevent new pods from being scheduled to that
|
||||
node, but will not affect any existing pods on the node. This is useful as a
|
||||
preparatory step before a node reboot, etc. For example, to mark a node
|
||||
unschedulable, run this command:
|
||||
|
||||
@@ -3,7 +3,7 @@ assignees:
|
||||
- derekwaynecarr
|
||||
- vishh
|
||||
- timstclair
|
||||
|
||||
title: Configuring Out Of Resource Handling
|
||||
---
|
||||
|
||||
* TOC
|
||||
@@ -349,7 +349,7 @@ in favor of the simpler configuation supported around eviction.
|
||||
The `kubelet` currently polls `cAdvisor` to collect memory usage stats at a regular interval. If memory usage
|
||||
increases within that window rapidly, the `kubelet` may not observe `MemoryPressure` fast enough, and the `OOMKiller`
|
||||
will still be invoked. We intend to integrate with the `memcg` notification API in a future release to reduce this
|
||||
latency, and instead have the kernel tell us when a threshold has been crossed immmediately.
|
||||
latency, and instead have the kernel tell us when a threshold has been crossed immediately.
|
||||
|
||||
If you are not trying to achieve extreme utilization, but a sensible measure of overcommit, a viable workaround for
|
||||
this issue is to set eviction thresholds at approximately 75% capacity. This increases the ability of this feature
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
assignees:
|
||||
- lavalamp
|
||||
- thockin
|
||||
|
||||
title: Kubernetes OpenVSwitch GRE/VxLAN networking
|
||||
---
|
||||
|
||||
This document describes how OpenVSwitch is used to setup networking between pods across nodes.
|
||||
|
||||
@@ -36,7 +36,7 @@ Each critical add-on has to tolerate it,
|
||||
the other pods shouldn't tolerate the taint. The tain is removed once the add-on is successfully scheduled.
|
||||
|
||||
*Warning:* currently there is no guarantee which node is chosen and which pods are being killed
|
||||
in order to schedule crical pod, so if rescheduler is enabled you pods might be occasionally
|
||||
in order to schedule critical pods, so if rescheduler is enabled you pods might be occasionally
|
||||
killed for this purpose.
|
||||
|
||||
## Config
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
|
||||
title: Resource Quotas
|
||||
---
|
||||
|
||||
When several users or teams share a cluster with a fixed number of nodes,
|
||||
@@ -125,7 +125,7 @@ The quota can be configured to quota either value.
|
||||
|
||||
If the quota has a value specified for `requests.cpu` or `requests.memory`, then it requires that every incoming
|
||||
container makes an explicit request for those resources. If the quota has a value specified for `limits.cpu` or `limits.memory`,
|
||||
then it requires that every incoming container specifies an explict limit for those resources.
|
||||
then it requires that every incoming container specifies an explicit limit for those resources.
|
||||
|
||||
## Viewing and Setting Quotas
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
assignees:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
|
||||
title: Applying Resource Quotas and Limits
|
||||
---
|
||||
|
||||
This example demonstrates a typical setup to control for resource usage in a namespace.
|
||||
@@ -232,7 +232,7 @@ services.loadbalancers 0 2
|
||||
services.nodeports 0 0
|
||||
```
|
||||
|
||||
As you can see, the pod that was created is consuming explict amounts of compute resources, and the usage is being
|
||||
As you can see, the pod that was created is consuming explicit amounts of compute resources, and the usage is being
|
||||
tracked by Kubernetes properly.
|
||||
|
||||
## Step 5: Advanced quota scopes
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
assignees:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
|
||||
title: Configuring Kubernetes with Salt
|
||||
---
|
||||
|
||||
The Kubernetes cluster can be configured using Salt.
|
||||
|
||||
@@ -4,7 +4,7 @@ assignees:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
- liggitt
|
||||
|
||||
title: Managing Service Accounts
|
||||
---
|
||||
|
||||
*This is a Cluster Administrator guide to service accounts. It assumes knowledge of
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
assignees:
|
||||
- jsafrane
|
||||
|
||||
title: Static Pods
|
||||
---
|
||||
|
||||
**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/)!**
|
||||
@@ -16,7 +16,7 @@ Static pod can be created in two ways: either by using configuration file(s) or
|
||||
|
||||
### Configuration files
|
||||
|
||||
The configuration files are just standard pod definition in json or yaml format in specific directory. Use `kubelet --config=<the directory>` to start kubelet daemon, which periodically scans the directory and creates/deletes static pods as yaml/json files appear/disappear there.
|
||||
The configuration files are just standard pod definition in json or yaml format in specific directory. Use `kubelet --pod-manifest-path=<the directory>` to start kubelet daemon, which periodically scans the directory and creates/deletes static pods as yaml/json files appear/disappear there.
|
||||
|
||||
For example, this is how to start a simple web server as a static pod:
|
||||
|
||||
@@ -48,10 +48,10 @@ For example, this is how to start a simple web server as a static pod:
|
||||
EOF
|
||||
```
|
||||
|
||||
2. Configure your kubelet daemon on the node to use this directory by running it with `--config=/etc/kubelet.d/` argument. On Fedora edit `/etc/kubernetes/kubelet` to include this line:
|
||||
2. Configure your kubelet daemon on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument. On Fedora edit `/etc/kubernetes/kubelet` to include this line:
|
||||
|
||||
```conf
|
||||
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --config=/etc/kubelet.d/"
|
||||
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
|
||||
```
|
||||
|
||||
Instructions for other distributions or Kubernetes installations may vary.
|
||||
@@ -64,11 +64,11 @@ For example, this is how to start a simple web server as a static pod:
|
||||
|
||||
## Pods created via HTTP
|
||||
|
||||
Kubelet periodically downloads a file specified by `--manifest-url=<URL>` argument and interprets it as a json/yaml file with a pod definition. It works the same as `--config=<directory>`, i.e. it's reloaded every now and then and changes are applied to running static pods (see below).
|
||||
Kubelet periodically downloads a file specified by `--manifest-url=<URL>` argument and interprets it as a json/yaml file with a pod definition. It works the same as `--pod-manifest-path=<directory>`, i.e. it's reloaded every now and then and changes are applied to running static pods (see below).
|
||||
|
||||
## Behavior of static pods
|
||||
|
||||
When kubelet starts, it automatically starts all pods defined in directory specified in `--config=` or `--manifest-url=` arguments, i.e. our static-web. (It may take some time to pull nginx image, be patient…):
|
||||
When kubelet starts, it automatically starts all pods defined in directory specified in `--pod-manifest-path=` or `--manifest-url=` arguments, i.e. our static-web. (It may take some time to pull nginx image, be patient…):
|
||||
|
||||
```shell
|
||||
[joe@my-node1 ~] $ docker ps
|
||||
|
||||
Reference in New Issue
Block a user