No more READMEs
This commit is contained in:
johndmulhausen
@@ -1,8 +1,6 @@
|
||||
---
|
||||
title: "End-2-End Testing in Kubernetes"
|
||||
---
|
||||
## Overview
|
||||
|
||||
The end-2-end tests for kubernetes provide a mechanism to test behavior of the system, and to ensure end user operations match developer specifications. In distributed systems it is not uncommon that a minor change may pass all unit tests, but cause unforseen changes at the system level. Thus, the primary objectives of the end-2-end tests are to ensure a consistent and reliable behavior of the kubernetes code base, and to catch bugs early.
|
||||
|
||||
The end-2-end tests in kubernetes are built atop of [ginkgo] (http://onsi.github.io/ginkgo/) and [gomega] (http://onsi.github.io/gomega/). There are a host of features that this BDD testing framework provides, and it is recommended that the developer read the documentation prior to diving into the tests.
|
||||
|
||||
@@ -1,178 +0,0 @@
|
||||
---
|
||||
title: "Picking the Right Solution"
|
||||
---
|
||||
Kubernetes can run on a range of platforms, from your laptop, to VMs on a cloud provider, to rack of
|
||||
bare metal servers. The effort required to set up a cluster varies from running a single command to
|
||||
crafting your own customized cluster. We'll guide you in picking a solution that fits for your needs.
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## Options
|
||||
|
||||
If you just want to "kick the tires" on Kubernetes, we recommend the [local Docker-based](docker) solution.
|
||||
|
||||
The local Docker-based solution is one of several [Local cluster](#local-machine-solutions) solutions
|
||||
that are quick to set up, but are limited to running on one machine.
|
||||
|
||||
When you are ready to scale up to more machines and higher availability, a [Hosted](#hosted-solutions)
|
||||
solution is the easiest to create and maintain.
|
||||
|
||||
[Turn-key cloud solutions](#turn-key-cloud-solutions) require only a few commands to create
|
||||
and cover a wider range of cloud providers.
|
||||
|
||||
[Custom solutions](#custom-solutions) require more effort to setup but cover and even
|
||||
they vary from step-by-step instructions to general advice for setting up
|
||||
a Kubernetes cluster from scratch.
|
||||
|
||||
### Local-machine Solutions
|
||||
|
||||
Local-machine solutions create a single cluster with one or more Kubernetes nodes on a single
|
||||
physical machine. Setup is completely automated and doesn't require a cloud provider account.
|
||||
But their size and availability is limited to that of a single machine.
|
||||
|
||||
The local-machine solutions are:
|
||||
|
||||
- [Local Docker-based](docker) (recommended starting point)
|
||||
- [Vagrant](vagrant) (works on any platform with Vagrant: Linux, MacOS, or Windows.)
|
||||
- [No-VM local cluster](locally) (Linux only)
|
||||
|
||||
|
||||
### Hosted Solutions
|
||||
|
||||
[Google Container Engine](https://cloud.google.com/container-engine) offers managed Kubernetes
|
||||
clusters.
|
||||
|
||||
### Turn-key Cloud Solutions
|
||||
|
||||
These solutions allow you to create Kubernetes clusters on a range of Cloud IaaS providers with only a
|
||||
few commands, and have active community support.
|
||||
|
||||
- [GCE](gce)
|
||||
- [AWS](aws)
|
||||
- [Azure](/{{page.version}}/docs/getting-started-guides/coreos/azure/)
|
||||
|
||||
### Custom Solutions
|
||||
|
||||
Kubernetes can run on a wide range of Cloud providers and bare-metal environments, and with many
|
||||
base operating systems.
|
||||
|
||||
If you can find a guide below that matches your needs, use it. It may be a little out of date, but
|
||||
it will be easier than starting from scratch. If you do want to start from scratch because you
|
||||
have special requirements or just because you want to understand what is underneath a Kubernetes
|
||||
cluster, try the [Getting Started from Scratch](scratch) guide.
|
||||
|
||||
If you are interested in supporting Kubernetes on a new platform, check out our [advice for
|
||||
writing a new solution](/{{page.version}}/docs/devel/writing-a-getting-started-guide).
|
||||
|
||||
#### Cloud
|
||||
|
||||
These solutions are combinations of cloud provider and OS not covered by the above solutions.
|
||||
|
||||
- [AWS + coreos](coreos)
|
||||
- [GCE + CoreOS](coreos)
|
||||
- [AWS + Ubuntu](juju)
|
||||
- [Joyent + Ubuntu](juju)
|
||||
- [Rackspace + CoreOS](rackspace)
|
||||
|
||||
#### On-Premises VMs
|
||||
|
||||
- [Vagrant](coreos) (uses CoreOS and flannel)
|
||||
- [CloudStack](cloudstack) (uses Ansible, CoreOS and flannel)
|
||||
- [Vmware](vsphere) (uses Debian)
|
||||
- [juju.md](juju) (uses Juju, Ubuntu and flannel)
|
||||
- [Vmware](coreos) (uses CoreOS and flannel)
|
||||
- [libvirt-coreos.md](libvirt-coreos) (uses CoreOS)
|
||||
- [oVirt](ovirt)
|
||||
- [libvirt](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster) (uses Fedora and flannel)
|
||||
- [KVM](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster) (uses Fedora and flannel)
|
||||
|
||||
#### Bare Metal
|
||||
|
||||
- [Offline](/{{page.version}}/docs/getting-started-guides/coreos/bare_metal_offline) (no internet required. Uses CoreOS and Flannel)
|
||||
- [fedora/fedora_ansible_config.md](/{{page.version}}/docs/getting-started-guides/fedora/fedora_ansible_config)
|
||||
- [Fedora single node](/{{page.version}}/docs/getting-started-guides/fedora/fedora_manual_config)
|
||||
- [Fedora multi node](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster)
|
||||
- [Centos](/{{page.version}}/docs/getting-started-guides/centos/centos_manual_config)
|
||||
- [Ubuntu](ubuntu)
|
||||
- [Docker Multi Node](docker-multinode)
|
||||
|
||||
#### Integrations
|
||||
|
||||
These solutions provide integration with 3rd party schedulers, resource managers, and/or lower level platforms.
|
||||
|
||||
- [Kubernetes on Mesos](mesos)
|
||||
- Instructions specify GCE, but are generic enough to be adapted to most existing Mesos clusters
|
||||
- [Kubernetes on DCOS](dcos)
|
||||
- Community Edition DCOS uses AWS
|
||||
- Enterprise Edition DCOS supports cloud hosting, on-premise VMs, and bare metal
|
||||
|
||||
## Table of Solutions
|
||||
|
||||
Here are all the solutions mentioned above in table form.
|
||||
|
||||
IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level
|
||||
-------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ----------------------------
|
||||
GKE | | | GCE | [docs](https://cloud.google.com/container-engine) | ['��][3] | Commercial
|
||||
Vagrant | Saltstack | Fedora | flannel | [docs](vagrant) | ['��][2] | Project
|
||||
GCE | Saltstack | Debian | GCE | [docs](gce) | ['��][1] | Project
|
||||
Azure | CoreOS | CoreOS | Weave | [docs](/{{page.version}}/docs/getting-started-guides/coreos/azure/) | | Community ([@errordeveloper](https://github.com/errordeveloper), [@squillace](https://github.com/squillace), [@chanezon](https://github.com/chanezon), [@crossorigin](https://github.com/crossorigin))
|
||||
Docker Single Node | custom | N/A | local | [docs](docker) | | Project ([@brendandburns](https://github.com/brendandburns))
|
||||
Docker Multi Node | Flannel | N/A | local | [docs](docker-multinode) | | Project ([@brendandburns](https://github.com/brendandburns))
|
||||
Bare-metal | Ansible | Fedora | flannel | [docs](/{{page.version}}/docs/getting-started-guides/fedora/fedora_ansible_config) | | Project
|
||||
Digital Ocean | custom | Fedora | Calico | [docs](/{{page.version}}/docs/getting-started-guides/fedora/fedora-calico) | | Community (@djosborne)
|
||||
Bare-metal | custom | Fedora | _none_ | [docs](/{{page.version}}/docs/getting-started-guides/fedora/fedora_manual_config) | | Project
|
||||
Bare-metal | custom | Fedora | flannel | [docs](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
libvirt | custom | Fedora | flannel | [docs](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
KVM | custom | Fedora | flannel | [docs](/{{page.version}}/docs/getting-started-guides/fedora/flannel_multi_node_cluster) | | Community ([@aveshagarwal](https://github.com/aveshagarwal))
|
||||
Mesos/Docker | custom | Ubuntu | Docker | [docs](mesos-docker) | | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
|
||||
Mesos/GCE | | | | [docs](mesos) | | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
|
||||
DCOS | Marathon | CoreOS/Alpine | custom | [docs](dcos) | | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md))
|
||||
AWS | CoreOS | CoreOS | flannel | [docs](coreos) | | Community
|
||||
GCE | CoreOS | CoreOS | flannel | [docs](coreos) | | Community ([@pires](https://github.com/pires))
|
||||
Vagrant | CoreOS | CoreOS | flannel | [docs](coreos) | | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles))
|
||||
Bare-metal (Offline) | CoreOS | CoreOS | flannel | [docs](/{{page.version}}/docs/getting-started-guides/coreos/bare_metal_offline) | | Community ([@jeffbean](https://github.com/jeffbean))
|
||||
Bare-metal | CoreOS | CoreOS | Calico | [docs](/{{page.version}}/docs/getting-started-guides/coreos/bare_metal_calico) | | Community ([@caseydavenport](https://github.com/caseydavenport))
|
||||
CloudStack | Ansible | CoreOS | flannel | [docs](cloudstack) | | Community ([@runseb](https://github.com/runseb))
|
||||
Vmware | | Debian | OVS | [docs](vsphere) | | Community ([@pietern](https://github.com/pietern))
|
||||
Bare-metal | custom | CentOS | _none_ | [docs](/{{page.version}}/docs/getting-started-guides/centos/centos_manual_config) | | Community ([@coolsvap](https://github.com/coolsvap))
|
||||
AWS | Juju | Ubuntu | flannel | [docs](juju) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
|
||||
OpenStack/HPCloud | Juju | Ubuntu | flannel | [docs](juju) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
|
||||
Joyent | Juju | Ubuntu | flannel | [docs](juju) | | [Community](https://github.com/whitmo/bundle-kubernetes) ( [@whit](https://github.com/whitmo), [@matt](https://github.com/mbruzek), [@chuck](https://github.com/chuckbutler) )
|
||||
AWS | Saltstack | Ubuntu | OVS | [docs](aws) | | Community ([@justinsb](https://github.com/justinsb))
|
||||
Bare-metal | custom | Ubuntu | Calico | [docs](ubuntu-calico) | | Community ([@djosborne](https://github.com/djosborne))
|
||||
Bare-metal | custom | Ubuntu | flannel | [docs](ubuntu) | | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY))
|
||||
Local | | | _none_ | [docs](locally) | | Community ([@preillyme](https://github.com/preillyme))
|
||||
libvirt/KVM | CoreOS | CoreOS | libvirt/KVM | [docs](libvirt-coreos) | | Community ([@lhuard1A](https://github.com/lhuard1A))
|
||||
oVirt | | | | [docs](ovirt) | | Community ([@simon3z](https://github.com/simon3z))
|
||||
Rackspace | CoreOS | CoreOS | flannel | [docs](rackspace) | | Community ([@doublerr](https://github.com/doublerr))
|
||||
any | any | any | any | [docs](scratch) | | Community ([@erictune](https://github.com/erictune))
|
||||
|
||||
|
||||
*Note*: The above table is ordered by version test/used in notes followed by support level.
|
||||
|
||||
Definition of columns:
|
||||
|
||||
- **IaaS Provider** is who/what provides the virtual or physical machines (nodes) that Kubernetes runs on.
|
||||
- **OS** is the base operating system of the nodes.
|
||||
- **Config. Mgmt** is the configuration management system that helps install and maintain Kubernetes software on the
|
||||
nodes.
|
||||
- **Networking** is what implements the [networking model](/{{page.version}}/docs/admin/networking). Those with networking type
|
||||
_none_ may not support more than one node, or may support multiple VM nodes only in the same physical node.
|
||||
- **Conformance** indicates whether a cluster created with this configuration has passed the project's conformance
|
||||
tests for supporting the API and base features of Kubernetes v1.0.0.
|
||||
- Support Levels
|
||||
- **Project**: Kubernetes Committers regularly use this configuration, so it usually works with the latest release
|
||||
of Kubernetes.
|
||||
- **Commercial**: A commercial offering with its own support arrangements.
|
||||
- **Community**: Actively supported by community contributions. May not work with more recent releases of Kubernetes.
|
||||
- **Inactive**: No active maintainer. Not recommended for first-time Kubernetes users, and may be deleted soon.
|
||||
- **Notes** is relevant information such as the version of Kubernetes used.
|
||||
|
||||
<!-- reference style links below here -->
|
||||
<!-- GCE conformance test result -->
|
||||
[1]: https://gist.github.com/erictune/4cabc010906afbcc5061
|
||||
<!-- Vagrant conformance test result -->
|
||||
[2]: https://gist.github.com/derekwaynecarr/505e56036cdf010bf6b6
|
||||
<!-- GKE conformance test result -->
|
||||
[3]: https://gist.github.com/erictune/2f39b22f72565365e59b
|
||||
@@ -1,9 +1,6 @@
|
||||
---
|
||||
title: "Getting started on CloudStack"
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
CloudStack is a software to build public and private clouds based on hardware virtualization principles (traditional IaaS). To deploy Kubernetes on CloudStack there are several possibilities depending on the Cloud being used and what images are made available. [Exoscale](http://exoscale.ch) for instance makes a [CoreOS](http://coreos.com) template available, therefore instructions to deploy Kubernetes on coreOS can be used. CloudStack also has a vagrant plugin available, hence Vagrant could be used to deploy Kubernetes either using the existing shell provisioner or using new Salt based recipes.
|
||||
|
||||
[CoreOS](http://coreos.com) templates for CloudStack are built [nightly](http://stable.release.core-os.net/amd64-usr/current/). CloudStack operators need to [register](http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/templates) this template in their cloud before proceeding with these Kubernetes deployment instructions.
|
||||
|
||||
@@ -1,222 +0,0 @@
|
||||
---
|
||||
title: "Kubernetes on Azure with CoreOS and Weave"
|
||||
---
|
||||
In this guide I will demonstrate how to deploy a Kubernetes cluster to Azure cloud. You will be using CoreOS with Weave, which implements simple and secure networking, in a transparent, yet robust way. The purpose of this guide is to provide an out-of-the-box implementation that can ultimately be taken into production with little change. It will demonstrate how to provision a dedicated Kubernetes master and etcd nodes, and show how to scale the cluster with ease.
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
### Prerequisites
|
||||
|
||||
1. You need an Azure account.
|
||||
|
||||
## Let's go!
|
||||
|
||||
To get started, you need to checkout the code:
|
||||
|
||||
```shell
|
||||
git clone https://github.com/kubernetes/kubernetes
|
||||
cd kubernetes/docs/getting-started-guides/coreos/azure/
|
||||
```
|
||||
|
||||
You will need to have [Node.js installed](http://nodejs.org/download/) on you machine. If you have previously used Azure CLI, you should have it already.
|
||||
|
||||
First, you need to install some of the dependencies with
|
||||
|
||||
```shell
|
||||
npm install
|
||||
```
|
||||
|
||||
Now, all you need to do is:
|
||||
|
||||
```shell
|
||||
./azure-login.js -u <your_username>
|
||||
./create-kubernetes-cluster.js
|
||||
```
|
||||
|
||||
This script will provision a cluster suitable for production use, where there is a ring of 3 dedicated etcd nodes: 1 kubernetes master and 2 kubernetes nodes. The `kube-00` VM will be the master, your work loads are only to be deployed on the nodes, `kube-01` and `kube-02`. Initially, all VMs are single-core, to ensure a user of the free tier can reproduce it without paying extra. I will show how to add more bigger VMs later.
|
||||
|
||||
|
||||
|
||||
Once the creation of Azure VMs has finished, you should see the following:
|
||||
|
||||
```shell
|
||||
...
|
||||
azure_wrapper/info: Saved SSH config, you can use it like so: `ssh -F ./output/kube_1c1496016083b4_ssh_conf <hostname>`
|
||||
azure_wrapper/info: The hosts in this deployment are:
|
||||
[ 'etcd-00', 'etcd-01', 'etcd-02', 'kube-00', 'kube-01', 'kube-02' ]
|
||||
azure_wrapper/info: Saved state into `./output/kube_1c1496016083b4_deployment.yml`
|
||||
```
|
||||
|
||||
Let's login to the master node like so:
|
||||
|
||||
```shell
|
||||
ssh -F ./output/kube_1c1496016083b4_ssh_conf kube-00
|
||||
```
|
||||
|
||||
> Note: config file name will be different, make sure to use the one you see.
|
||||
|
||||
Check there are 2 nodes in the cluster:
|
||||
|
||||
```shell
|
||||
core@kube-00 ~ $ kubectl get nodes
|
||||
NAME LABELS STATUS
|
||||
kube-01 kubernetes.io/hostname=kube-01 Ready
|
||||
kube-02 kubernetes.io/hostname=kube-02 Ready
|
||||
```
|
||||
|
||||
## Deploying the workload
|
||||
|
||||
Let's follow the Guestbook example now:
|
||||
|
||||
```shell
|
||||
kubectl create -f ~/guestbook-example
|
||||
```
|
||||
|
||||
You need to wait for the pods to get deployed, run the following and wait for `STATUS` to change from `Pending` to `Running`.
|
||||
|
||||
```shell
|
||||
kubectl get pods --watch
|
||||
```
|
||||
|
||||
> Note: the most time it will spend downloading Docker container images on each of the nodes.
|
||||
|
||||
Eventually you should see:
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-0a9xi 1/1 Running 0 4m
|
||||
frontend-4wahe 1/1 Running 0 4m
|
||||
frontend-6l36j 1/1 Running 0 4m
|
||||
redis-master-talmr 1/1 Running 0 4m
|
||||
redis-slave-12zfd 1/1 Running 0 4m
|
||||
redis-slave-3nbce 1/1 Running 0 4m
|
||||
```
|
||||
|
||||
## Scaling
|
||||
|
||||
Two single-core nodes are certainly not enough for a production system of today. Let's scale the cluster by adding a couple of bigger nodes.
|
||||
|
||||
You will need to open another terminal window on your machine and go to the same working directory (e.g. `~/Workspace/kubernetes/docs/getting-started-guides/coreos/azure/`).
|
||||
|
||||
First, lets set the size of new VMs:
|
||||
|
||||
```shell
|
||||
export AZ_VM_SIZE=Large
|
||||
```
|
||||
|
||||
Now, run scale script with state file of the previous deployment and number of nodes to add:
|
||||
|
||||
```shell
|
||||
core@kube-00 ~ $ ./scale-kubernetes-cluster.js ./output/kube_1c1496016083b4_deployment.yml 2
|
||||
...
|
||||
azure_wrapper/info: Saved SSH config, you can use it like so: `ssh -F ./output/kube_8f984af944f572_ssh_conf <hostname>`
|
||||
azure_wrapper/info: The hosts in this deployment are:
|
||||
[ 'etcd-00',
|
||||
'etcd-01',
|
||||
'etcd-02',
|
||||
'kube-00',
|
||||
'kube-01',
|
||||
'kube-02',
|
||||
'kube-03',
|
||||
'kube-04' ]
|
||||
azure_wrapper/info: Saved state into `./output/kube_8f984af944f572_deployment.yml`
|
||||
```
|
||||
|
||||
> Note: this step has created new files in `./output`.
|
||||
|
||||
Back on `kube-00`:
|
||||
|
||||
```shell
|
||||
core@kube-00 ~ $ kubectl get nodes
|
||||
NAME LABELS STATUS
|
||||
kube-01 kubernetes.io/hostname=kube-01 Ready
|
||||
kube-02 kubernetes.io/hostname=kube-02 Ready
|
||||
kube-03 kubernetes.io/hostname=kube-03 Ready
|
||||
kube-04 kubernetes.io/hostname=kube-04 Ready
|
||||
```
|
||||
|
||||
You can see that two more nodes joined happily. Let's scale the number of Guestbook instances now.
|
||||
|
||||
First, double-check how many replication controllers there are:
|
||||
|
||||
```shell
|
||||
core@kube-00 ~ $ kubectl get rc
|
||||
ONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
|
||||
frontend php-redis kubernetes/example-guestbook-php-redis:v2 name=frontend 3
|
||||
redis-master master redis name=redis-master 1
|
||||
redis-slave worker kubernetes/redis-slave:v2 name=redis-slave 2
|
||||
```
|
||||
|
||||
As there are 4 nodes, let's scale proportionally:
|
||||
|
||||
```shell
|
||||
core@kube-00 ~ $ kubectl scale --replicas=4 rc redis-slave
|
||||
>>>>>>> coreos/azure: Updates for 1.0
|
||||
scaled
|
||||
core@kube-00 ~ $ kubectl scale --replicas=4 rc frontend
|
||||
scaled
|
||||
```
|
||||
|
||||
Check what you have now:
|
||||
|
||||
```shell
|
||||
core@kube-00 ~ $ kubectl get rc
|
||||
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
|
||||
frontend php-redis kubernetes/example-guestbook-php-redis:v2 name=frontend 4
|
||||
redis-master master redis name=redis-master 1
|
||||
redis-slave worker kubernetes/redis-slave:v2 name=redis-slave 4
|
||||
```
|
||||
|
||||
You now will have more instances of front-end Guestbook apps and Redis slaves; and, if you look up all pods labeled `name=frontend`, you should see one running on each node.
|
||||
|
||||
```shell
|
||||
core@kube-00 ~/guestbook-example $ kubectl get pods -l name=frontend
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-0a9xi 1/1 Running 0 22m
|
||||
frontend-4wahe 1/1 Running 0 22m
|
||||
frontend-6l36j 1/1 Running 0 22m
|
||||
frontend-z9oxo 1/1 Running 0 41s
|
||||
```
|
||||
|
||||
## Exposing the app to the outside world
|
||||
|
||||
There is no native Azure load-balancer support in Kubernetes 1.0, however here is how you can expose the Guestbook app to the Internet.
|
||||
|
||||
```shell
|
||||
./expose_guestbook_app_port.sh ./output/kube_1c1496016083b4_ssh_conf
|
||||
Guestbook app is on port 31605, will map it to port 80 on kube-00
|
||||
info: Executing command vm endpoint create
|
||||
+ Getting virtual machines
|
||||
+ Reading network configuration
|
||||
+ Updating network configuration
|
||||
info: vm endpoint create command OK
|
||||
info: Executing command vm endpoint show
|
||||
+ Getting virtual machines
|
||||
data: Name : tcp-80-31605
|
||||
data: Local port : 31605
|
||||
data: Protcol : tcp
|
||||
data: Virtual IP Address : 137.117.156.164
|
||||
data: Direct server return : Disabled
|
||||
info: vm endpoint show command OK
|
||||
```
|
||||
|
||||
You then should be able to access it from anywhere via the Azure virtual IP for `kube-00` displayed above, i.e. `http://137.117.156.164/` in my case.
|
||||
|
||||
## Next steps
|
||||
|
||||
You now have a full-blow cluster running in Azure, congrats!
|
||||
|
||||
You should probably try deploy other [example apps](../../../../examples/) or write your own ;)
|
||||
|
||||
## Tear down...
|
||||
|
||||
If you don't wish care about the Azure bill, you can tear down the cluster. It's easy to redeploy it, as you can see.
|
||||
|
||||
```shell
|
||||
./destroy-cluster.js ./output/kube_8f984af944f572_deployment.yml
|
||||
```
|
||||
|
||||
> Note: make sure to use the _latest state file_, as after scaling there is a new one.
|
||||
|
||||
By the way, with the scripts shown, you can deploy multiple clusters, if you like :)
|
||||
@@ -7,12 +7,8 @@ Use the [master.yaml](cloud-configs/master.yaml) and [node.yaml](cloud-configs/n
|
||||
|
||||
[coreos695]: https://coreos.com/releases/#695.0.0
|
||||
|
||||
## Overview
|
||||
|
||||
* Provision the master node
|
||||
* Capture the master node private IP address
|
||||
* Edit node.yaml
|
||||
* Provision one or more worker nodes
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
### AWS
|
||||
|
||||
|
||||
@@ -1,6 +1,12 @@
|
||||
---
|
||||
title: "Running Multi-Node Kubernetes Using Docker"
|
||||
---
|
||||
This guide will set up a 2-node Kubernetes cluster, consisting of a _master_ node which hosts the API server and orchestrates work
|
||||
and a _worker_ node which receives work from the master. You can repeat the process of adding worker nodes an arbitrary number of
|
||||
times to create larger clusters.
|
||||
|
||||
Here's a diagram of what the final result will look like:
|
||||
|
||||
|
||||
_Note_:
|
||||
These instructions are somewhat significantly more advanced than the [single node](docker) instructions. If you are
|
||||
@@ -15,16 +21,7 @@ Please install Docker 1.6.2 or Docker 1.7.1.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. You need a machine with docker of right version installed.
|
||||
|
||||
## Overview
|
||||
|
||||
This guide will set up a 2-node Kubernetes cluster, consisting of a _master_ node which hosts the API server and orchestrates work
|
||||
and a _worker_ node which receives work from the master. You can repeat the process of adding worker nodes an arbitrary number of
|
||||
times to create larger clusters.
|
||||
|
||||
Here's a diagram of what the final result will look like:
|
||||
|
||||
You need a machine with docker of right version installed.
|
||||
|
||||
### Bootstrap Docker
|
||||
|
||||
|
||||
@@ -1,15 +1,6 @@
|
||||
---
|
||||
title: "Running Kubernetes with Calico Networking on a Digital Ocean Fedora Host"
|
||||
---
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
You need two or more Fedora 22 droplets on Digital Ocean with [Private Networking](https://www.digitalocean.com/community/tutorials/how-to-set-up-and-use-digitalocean-private-networking) enabled.
|
||||
|
||||
## Overview
|
||||
|
||||
This guide will walk you through the process of getting a Kubernetes Fedora cluster running on Digital Ocean with networking powered by Calico networking.
|
||||
It will cover the installation and configuration of the following systemd processes on the following hosts:
|
||||
|
||||
@@ -41,6 +32,13 @@ and [add an entry to /etc/hosts for each host](#setup-communication-between-host
|
||||
|
||||
Ensure you substitute the IP Addresses and Hostnames used in this guide with ones in your own setup.
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
You need two or more Fedora 22 droplets on Digital Ocean with [Private Networking](https://www.digitalocean.com/community/tutorials/how-to-set-up-and-use-digitalocean-private-networking) enabled.
|
||||
|
||||
## Setup Communication Between Hosts
|
||||
|
||||
Digital Ocean private networking configures a private network on eth1 for each host. To simplify communication between the hosts, we will add an entry to /etc/hosts
|
||||
|
||||
@@ -1,138 +0,0 @@
|
||||
---
|
||||
title: "Run Kubernetes with rkt"
|
||||
---
|
||||
This document describes how to run Kubernetes using [rkt](https://github.com/coreos/rkt) as a container runtime.
|
||||
We still have [a bunch of work](http://issue.k8s.io/8262) to do to make the experience with rkt wonderful, please stay tuned!
|
||||
|
||||
### **Prerequisite**
|
||||
|
||||
- [systemd](http://www.freedesktop.org/wiki/Software/systemd/) should be installed on the machine and should be enabled. The minimum version required at this moment (2015/09/01) is 219
|
||||
*(Note that systemd is not required by rkt itself, we are using it here to monitor and manage the pods launched by kubelet.)*
|
||||
|
||||
- Install the latest rkt release according to the instructions [here](https://github.com/coreos/rkt).
|
||||
The minimum version required for now is [v0.8.0](https://github.com/coreos/rkt/releases/tag/v0.8.0).
|
||||
|
||||
- Note that for rkt version later than v0.7.0, `metadata service` is not required for running pods in private networks. So now rkt pods will not register the metadata service be default.
|
||||
|
||||
### Local cluster
|
||||
|
||||
To use rkt as the container runtime, we need to supply `--container-runtime=rkt` and `--rkt-path=$PATH_TO_RKT_BINARY` to kubelet. Additionally we can provide `--rkt-stage1-image` flag
|
||||
as well to select which [stage1 image](https://github.com/coreos/rkt/blob/master/Documentation/running-lkvm-stage1.md) we want to use.
|
||||
|
||||
If you are using the [hack/local-up-cluster.sh](https://releases.k8s.io/release-1.1/hack/local-up-cluster.sh) script to launch the local cluster, then you can edit the environment variable `CONTAINER_RUNTIME`, `RKT_PATH` and `RKT_STAGE1_IMAGE` to
|
||||
set these flags:
|
||||
|
||||
```shell
|
||||
$ export CONTAINER_RUNTIME=rkt
|
||||
$ export RKT_PATH=$PATH_TO_RKT_BINARY
|
||||
$ export RKT_STAGE1_IMAGE=PATH=$PATH_TO_STAGE1_IMAGE
|
||||
```
|
||||
|
||||
Then we can launch the local cluster using the script:
|
||||
|
||||
```shell
|
||||
$ hack/local-up-cluster.sh
|
||||
```
|
||||
|
||||
### CoreOS cluster on Google Compute Engine (GCE)
|
||||
|
||||
To use rkt as the container runtime for your CoreOS cluster on GCE, you need to specify the OS distribution, project, image:
|
||||
|
||||
```shell
|
||||
$ export KUBE_OS_DISTRIBUTION=coreos
|
||||
$ export KUBE_GCE_MINION_IMAGE=<image_id>
|
||||
$ export KUBE_GCE_MINION_PROJECT=coreos-cloud
|
||||
$ export KUBE_CONTAINER_RUNTIME=rkt
|
||||
```
|
||||
|
||||
You can optionally choose the version of rkt used by setting `KUBE_RKT_VERSION`:
|
||||
|
||||
```shell
|
||||
$ export KUBE_RKT_VERSION=0.8.0
|
||||
```
|
||||
|
||||
Then you can launch the cluster by:
|
||||
|
||||
```shell
|
||||
$ kube-up.sh
|
||||
```
|
||||
|
||||
Note that we are still working on making all containerized the master components run smoothly in rkt. Before that we are not able to run the master node with rkt yet.
|
||||
|
||||
### CoreOS cluster on AWS
|
||||
|
||||
To use rkt as the container runtime for your CoreOS cluster on AWS, you need to specify the provider and OS distribution:
|
||||
|
||||
```shell
|
||||
$ export KUBERNETES_PROVIDER=aws
|
||||
$ export KUBE_OS_DISTRIBUTION=coreos
|
||||
$ export KUBE_CONTAINER_RUNTIME=rkt
|
||||
```
|
||||
|
||||
You can optionally choose the version of rkt used by setting `KUBE_RKT_VERSION`:
|
||||
|
||||
```shell
|
||||
$ export KUBE_RKT_VERSION=0.8.0
|
||||
```
|
||||
|
||||
You can optionally choose the CoreOS channel by setting `COREOS_CHANNEL`:
|
||||
|
||||
```shell
|
||||
$ export COREOS_CHANNEL=stable
|
||||
```
|
||||
|
||||
Then you can launch the cluster by:
|
||||
|
||||
```shell
|
||||
$ kube-up.sh
|
||||
```
|
||||
|
||||
Note: CoreOS is not supported as the master using the automated launch
|
||||
scripts. The master node is always Ubuntu.
|
||||
|
||||
### Getting started with your cluster
|
||||
|
||||
See [a simple nginx example](/{{page.version}}/docs/user-guide/simple-nginx) to try out your new cluster.
|
||||
|
||||
For more complete applications, please look in the [examples directory](https://github.com/kubernetes/kubernetes/tree/master/examples/).
|
||||
|
||||
|
||||
### Debugging
|
||||
|
||||
Here are severals tips for you when you run into any issues.
|
||||
|
||||
##### Check logs
|
||||
|
||||
By default, the log verbose level is 2. In order to see more logs related to rkt, we can set the verbose level to 4.
|
||||
For local cluster, we can set the environment variable: `LOG_LEVEL=4`.
|
||||
If the cluster is using salt, we can edit the [logging.sls](https://releases.k8s.io/release-1.1/cluster/saltbase/pillar/logging.sls) in the saltbase.
|
||||
|
||||
##### Check rkt pod status
|
||||
|
||||
To check the pods' status, we can use rkt command, such as `rkt list`, `rkt status`, `rkt image list`, etc.
|
||||
More information about rkt command line can be found [here](https://github.com/coreos/rkt/blob/master/Documentation/commands.md)
|
||||
|
||||
##### Check journal logs
|
||||
|
||||
As we use systemd to launch rkt pods(by creating service files which will run `rkt run-prepared`, we can check the pods' log
|
||||
using `journalctl`:
|
||||
|
||||
- Check the running state of the systemd service:
|
||||
|
||||
```shell
|
||||
$ sudo journalctl -u $SERVICE_FILE
|
||||
```
|
||||
|
||||
where `$SERVICE_FILE` is the name of the service file created for the pod, you can find it in the kubelet logs.
|
||||
|
||||
##### Check the log of the container in the pod:
|
||||
|
||||
```shell
|
||||
$ sudo journalctl -M rkt-$UUID -u $CONTAINER_NAME
|
||||
```
|
||||
|
||||
where `$UUID` is the rkt pod's UUID, which you can find via `rkt list --full`, and `$CONTAINER_NAME` is the container's name.
|
||||
|
||||
##### Check Kubernetes events, logs.
|
||||
|
||||
Besides above tricks, Kubernetes also provides us handy tools for debugging the pods. More information can be found [here](/{{page.version}}/docs/user-guide/application-troubleshooting).
|
||||
@@ -1,8 +1,6 @@
|
||||
---
|
||||
title: "Kubernetes Deployment On Bare-metal Ubuntu Nodes with Calico Networking"
|
||||
---
|
||||
## Introduction
|
||||
|
||||
This document describes how to deploy Kubernetes on Ubuntu bare metal nodes with Calico Networking plugin. See [projectcalico.org](http://projectcalico.org) for more information on what Calico is, and [the calicoctl github](https://github.com/projectcalico/calico-docker) for more information on the command-line tool, `calicoctl`.
|
||||
|
||||
This guide will set up a simple Kubernetes cluster with a master and two nodes. We will start the following processes with systemd:
|
||||
|
||||
@@ -1,90 +0,0 @@
|
||||
---
|
||||
title: "Kubernetes User Guide: Managing Applications"
|
||||
---
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster. Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/{{page.version}}/docs/admin/). The [Developer Guide](/{{page.version}}/docs/devel/) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project.
|
||||
|
||||
Please ensure you have completed the [prerequisites for running examples from the user guide](prereqs).
|
||||
|
||||
## Quick walkthrough
|
||||
|
||||
1. [Kubernetes 101](walkthrough/)
|
||||
1. [Kubernetes 201](walkthrough/k8s201)
|
||||
|
||||
## Thorough walkthrough
|
||||
|
||||
If you don't have much familiarity with Kubernetes, we recommend you read the following sections in order:
|
||||
|
||||
1. [Quick start: launch and expose an application](quick-start)
|
||||
1. [Configuring and launching containers: configuring common container parameters](configuring-containers)
|
||||
1. [Deploying continuously running applications](deploying-applications)
|
||||
1. [Connecting applications: exposing applications to clients and users](connecting-applications)
|
||||
1. [Working with containers in production](production-pods)
|
||||
1. [Managing deployments](managing-deployments)
|
||||
1. [Application introspection and debugging](introspection-and-debugging)
|
||||
1. [Using the Kubernetes web user interface](ui)
|
||||
1. [Logging](logging)
|
||||
1. [Monitoring](monitoring)
|
||||
1. [Getting into containers via `exec`](getting-into-containers)
|
||||
1. [Connecting to containers via proxies](connecting-to-applications-proxy)
|
||||
1. [Connecting to containers via port forwarding](connecting-to-applications-port-forward)
|
||||
|
||||
## Concept guide
|
||||
|
||||
[**Overview**](overview)
|
||||
: A brief overview of Kubernetes concepts.
|
||||
|
||||
[**Cluster**](/{{page.version}}/docs/admin/)
|
||||
: A cluster is a set of physical or virtual machines and other infrastructure resources used by Kubernetes to run your applications.
|
||||
|
||||
[**Node**](/{{page.version}}/docs/admin/node)
|
||||
: A node is a physical or virtual machine running Kubernetes, onto which pods can be scheduled.
|
||||
|
||||
[**Pod**](pods)
|
||||
: A pod is a co-located group of containers and volumes.
|
||||
|
||||
[**Label**](labels)
|
||||
: A label is a key/value pair that is attached to a resource, such as a pod, to convey a user-defined identifying attribute. Labels can be used to organize and to select subsets of resources.
|
||||
|
||||
[**Selector**](labels/#label-selectors)
|
||||
: A selector is an expression that matches labels in order to identify related resources, such as which pods are targeted by a load-balanced service.
|
||||
|
||||
[**Replication Controller**](replication-controller)
|
||||
: A replication controller ensures that a specified number of pod replicas are running at any one time. It both allows for easy scaling of replicated systems and handles re-creation of a pod when the machine it is on reboots or otherwise fails.
|
||||
|
||||
[**Service**](services)
|
||||
: A service defines a set of pods and a means by which to access them, such as single stable IP address and corresponding DNS name.
|
||||
|
||||
[**Volume**](volumes)
|
||||
: A volume is a directory, possibly with some data in it, which is accessible to a Container as part of its filesystem. Kubernetes volumes build upon [Docker Volumes](https://docs.docker.com/userguide/dockervolumes/), adding provisioning of the volume directory and/or device.
|
||||
|
||||
[**Secret**](secrets)
|
||||
: A secret stores sensitive data, such as authentication tokens, which can be made available to containers upon request.
|
||||
|
||||
[**Name**](identifiers)
|
||||
: A user- or client-provided name for a resource.
|
||||
|
||||
[**Namespace**](namespaces)
|
||||
: A namespace is like a prefix to the name of a resource. Namespaces help different projects, teams, or customers to share a cluster, such as by preventing name collisions between unrelated teams.
|
||||
|
||||
[**Annotation**](annotations)
|
||||
: A key/value pair that can hold larger (compared to a label), and possibly not human-readable, data, intended to store non-identifying auxiliary data, especially data manipulated by tools and system extensions. Efficient filtering by annotation values is not supported.
|
||||
|
||||
## Further reading
|
||||
|
||||
* API resources
|
||||
* [Working with resources](working-with-resources)
|
||||
|
||||
* Pods and containers
|
||||
* [Pod lifecycle and restart policies](pod-states)
|
||||
* [Lifecycle hooks](container-environment)
|
||||
* [Compute resources, such as cpu and memory](compute-resources)
|
||||
* [Specifying commands and requesting capabilities](containers)
|
||||
* [Downward API: accessing system configuration from a pod](downward-api)
|
||||
* [Images and registries](images)
|
||||
* [Migrating from docker-cli to kubectl](docker-cli-to-kubectl)
|
||||
* [Tips and tricks when working with config](config-best-practices)
|
||||
* [Assign pods to selected nodes](node-selection/)
|
||||
* [Perform a rolling update on a running group of pods](update-demo/)
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: "Downward API example"
|
||||
---
|
||||
Following this example, you will create a pod with a container that consumes the pod's name and
|
||||
namespace using the [downward API](../downward-api).
|
||||
|
||||
## Step Zero: Prerequisites
|
||||
|
||||
This example assumes you have a Kubernetes cluster installed and running, and that you have
|
||||
installed the `kubectl` command line tool somewhere in your path. Please see the [getting
|
||||
started](/{{page.version}}/docs/getting-started-guides/) for installation instructions for your platform.
|
||||
|
||||
## Step One: Create the pod
|
||||
|
||||
Containers consume the downward API using environment variables. The downward API allows
|
||||
containers to be injected with the name and namespace of the pod the container is in.
|
||||
|
||||
Use the [`examples/downward-api/dapi-pod.yaml`](dapi-pod.yaml) file to create a Pod with a container that consumes the
|
||||
downward API.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/downward-api/dapi-pod.yaml
|
||||
|
||||
```
|
||||
### Examine the logs
|
||||
|
||||
This pod runs the `env` command in a container that consumes the downward API. You can grep
|
||||
through the pod logs to see that the pod was injected with the correct values:
|
||||
|
||||
```shell
|
||||
$ kubectl logs dapi-test-pod | grep POD_
|
||||
2015-04-30T20:22:18.568024817Z MY_POD_NAME=dapi-test-pod
|
||||
2015-04-30T20:22:18.568087688Z MY_POD_NAMESPACE=default
|
||||
2015-04-30T20:22:18.568092435Z MY_POD_IP=10.0.1.6
|
||||
|
||||
```
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
title: "Downward API volume plugin"
|
||||
---
|
||||
Following this example, you will create a pod with a downward API volume.
|
||||
A downward API volume is a k8s volume plugin with the ability to save some pod information in a plain text file. The pod information can be for example some [metadata](..//{{page.version}}/docs/devel/api-conventions/#metadata).
|
||||
|
||||
Supported metadata fields:
|
||||
|
||||
1. `metadata.annotations`
|
||||
2. `metadata.namespace`
|
||||
3. `metadata.name`
|
||||
4. `metadata.labels`
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
|
||||
This example assumes you have a Kubernetes cluster installed and running, and the ```kubectl```
|
||||
command line tool somewhere in your path. Please see the [gettingstarted](..//{{page.version}}/docs/getting-started-guides/) for installation instructions for your platform.
|
||||
|
||||
### Step One: Create the pod
|
||||
|
||||
Use the `docs/user-guide/downward-api/dapi-volume.yaml` file to create a Pod with a downward API volume which stores pod labels and pod annotations to `/etc/labels` and `/etc/annotations` respectively.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/downward-api/volume/dapi-volume.yaml
|
||||
|
||||
```
|
||||
### Step Two: Examine pod/container output
|
||||
|
||||
The pod displays (every 5 seconds) the content of the dump files which can be executed via the usual `kubectl log` command
|
||||
|
||||
```shell
|
||||
$ kubectl logs kubernetes-downwardapi-volume-example
|
||||
cluster="test-cluster1"
|
||||
rack="rack-22"
|
||||
zone="us-est-coast"
|
||||
build="two"
|
||||
builder="john-doe"
|
||||
kubernetes.io/config.seen="2015-08-24T13:47:23.432459138Z"
|
||||
kubernetes.io/config.source="api"
|
||||
|
||||
```
|
||||
### Internals
|
||||
|
||||
In pod's `/etc` directory one may find the file created by the plugin (system files elided):
|
||||
|
||||
```shell
|
||||
$ kubectl exec kubernetes-downwardapi-volume-example -i -t -- sh
|
||||
/ # ls -laR /etc
|
||||
/etc:
|
||||
total 32
|
||||
drwxrwxrwt 3 0 0 180 Aug 24 13:03 .
|
||||
drwxr-xr-x 1 0 0 4096 Aug 24 13:05 ..
|
||||
drwx------ 2 0 0 80 Aug 24 13:03 ..2015_08_24_13_03_44259413923
|
||||
lrwxrwxrwx 1 0 0 30 Aug 24 13:03 ..downwardapi -> ..2015_08_24_13_03_44259413923
|
||||
lrwxrwxrwx 1 0 0 25 Aug 24 13:03 annotations -> ..downwardapi/annotations
|
||||
lrwxrwxrwx 1 0 0 20 Aug 24 13:03 labels -> ..downwardapi/labels
|
||||
|
||||
/etc/..2015_08_24_13_03_44259413923:
|
||||
total 8
|
||||
drwx------ 2 0 0 80 Aug 24 13:03 .
|
||||
drwxrwxrwt 3 0 0 180 Aug 24 13:03 ..
|
||||
-rw-r--r-- 1 0 0 115 Aug 24 13:03 annotations
|
||||
-rw-r--r-- 1 0 0 53 Aug 24 13:03 labels
|
||||
/ #
|
||||
|
||||
```
|
||||
The file `labels` is stored in a temporary directory (`..2015_08_24_13_03_44259413923` in the example above) which is symlinked to by `..downwardapi`. Symlinks for annotations and labels in `/etc` point to files containing the actual metadata through the `..downwardapi` indirection. This structure allows for dynamic atomic refresh of the metadata: updates are written to a new temporary directory, and the `..downwardapi` symlink is updated atomically using `rename(2)`.
|
||||
@@ -1,89 +0,0 @@
|
||||
---
|
||||
title: "Environment Guide Example"
|
||||
---
|
||||
This example demonstrates running pods, replication controllers, and
|
||||
services. It shows two types of pods: frontend and backend, with
|
||||
services on top of both. Accessing the frontend pod will return
|
||||
environment information about itself, and a backend pod that it has
|
||||
accessed through the service. The goal is to illuminate the
|
||||
environment metadata available to running containers inside the
|
||||
Kubernetes cluster. The documentation for the Kubernetes environment
|
||||
is [here](/{{page.version}}/docs/user-guide/container-environment).
|
||||
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
This example assumes that you have a Kubernetes cluster installed and
|
||||
running, and that you have installed the `kubectl` command line tool
|
||||
somewhere in your path. Please see the [getting
|
||||
started](/{{page.version}}/docs/getting-started-guides/) for installation instructions
|
||||
for your platform.
|
||||
|
||||
### Optional: Build your own containers
|
||||
|
||||
The code for the containers is under
|
||||
[containers/](containers/)
|
||||
|
||||
## Get everything running
|
||||
|
||||
kubectl create -f ./backend-rc.yaml
|
||||
kubectl create -f ./backend-srv.yaml
|
||||
kubectl create -f ./show-rc.yaml
|
||||
kubectl create -f ./show-srv.yaml
|
||||
|
||||
## Query the service
|
||||
|
||||
Use `kubectl describe service show-srv` to determine the public IP of
|
||||
your service.
|
||||
|
||||
> Note: If your platform does not support external load balancers,
|
||||
you'll need to open the proper port and direct traffic to the
|
||||
internal IP shown for the frontend service with the above command
|
||||
|
||||
Run `curl <public ip>:80` to query the service. You should get
|
||||
something like this back:
|
||||
|
||||
```
|
||||
Pod Name: show-rc-xxu6i
|
||||
Pod Namespace: default
|
||||
USER_VAR: important information
|
||||
|
||||
Kubernetes environment variables
|
||||
BACKEND_SRV_SERVICE_HOST = 10.147.252.185
|
||||
BACKEND_SRV_SERVICE_PORT = 5000
|
||||
KUBERNETES_RO_SERVICE_HOST = 10.147.240.1
|
||||
KUBERNETES_RO_SERVICE_PORT = 80
|
||||
KUBERNETES_SERVICE_HOST = 10.147.240.2
|
||||
KUBERNETES_SERVICE_PORT = 443
|
||||
KUBE_DNS_SERVICE_HOST = 10.147.240.10
|
||||
KUBE_DNS_SERVICE_PORT = 53
|
||||
|
||||
Found backend ip: 10.147.252.185 port: 5000
|
||||
Response from backend
|
||||
Backend Container
|
||||
Backend Pod Name: backend-rc-6qiya
|
||||
Backend Namespace: default
|
||||
```
|
||||
|
||||
First the frontend pod's information is printed. The pod name and
|
||||
[namespace](https://github.com/kubernetes/kubernetes/blob/master/docs/design/namespaces) are retrieved from the
|
||||
[Downward API](/{{page.version}}/docs/user-guide/downward-api). Next, `USER_VAR` is the name of
|
||||
an environment variable set in the [pod
|
||||
definition](show-rc.yaml). Then, the dynamic Kubernetes environment
|
||||
variables are scanned and printed. These are used to find the backend
|
||||
service, named `backend-srv`. Finally, the frontend pod queries the
|
||||
backend service and prints the information returned. Again the backend
|
||||
pod returns its own pod name and namespace.
|
||||
|
||||
Try running the `curl` command a few times, and notice what
|
||||
changes. Ex: `watch -n 1 curl -s <ip>` Firstly, the frontend service
|
||||
is directing your request to different frontend pods each time. The
|
||||
frontend pods are always contacting the backend through the backend
|
||||
service. This results in a different backend pod servicing each
|
||||
request as well.
|
||||
|
||||
## Cleanup
|
||||
|
||||
kubectl delete rc,service -l type=show-type
|
||||
kubectl delete rc,service -l type=backend-type
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: "Building"
|
||||
---
|
||||
For each container, the build steps are the same. The examples below
|
||||
are for the `show` container. Replace `show` with `backend` for the
|
||||
backend container.
|
||||
|
||||
## Google Container Registry ([GCR](https://cloud.google.com/tools/container-registry/))
|
||||
|
||||
docker build -t gcr.io/<project-name>/show .
|
||||
gcloud docker push gcr.io/<project-name>/show
|
||||
|
||||
## Docker Hub
|
||||
|
||||
docker build -t <username>/show .
|
||||
docker push <username>/show
|
||||
|
||||
## Change Pod Definitions
|
||||
|
||||
Edit both `show-rc.yaml` and `backend-rc.yaml` and replace the
|
||||
specified `image:` with the one that you built.
|
||||
|
||||
|
||||
|
||||
@@ -1,186 +0,0 @@
|
||||
---
|
||||
title: "Horizontal Pod Autoscaler"
|
||||
---
|
||||
Horizontal pod autoscaling is a [beta](/{{page.version}}/docs/api/#api-versioning) feature in Kubernetes 1.1.
|
||||
It allows the number of pods in a replication controller or deployment to scale automatically based on observed CPU usage.
|
||||
In the future also other metrics will be supported.
|
||||
|
||||
In this document we explain how this feature works by walking you through an example of enabling horizontal pod autoscaling with the php-apache server.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
This example requires a running Kubernetes cluster and kubectl in the version at least 1.1.
|
||||
[Heapster](https://github.com/kubernetes/heapster) monitoring needs to be deployed in the cluster
|
||||
as horizontal pod autoscaler uses it to collect metrics
|
||||
(if you followed [getting started on GCE guide](/{{page.version}}/docs/getting-started-guides/gce),
|
||||
heapster monitoring will be turned-on by default).
|
||||
|
||||
|
||||
## Step One: Run & expose php-apache server
|
||||
|
||||
To demonstrate horizontal pod autoscaler we will use a custom docker image based on php-apache server.
|
||||
The image can be found [here](https://releases.k8s.io/release-1.1/docs/user-guide/horizontal-pod-autoscaling/image).
|
||||
It defines [index.php](image/index.php) page which performs some CPU intensive computations.
|
||||
|
||||
First, we will start a replication controller running the image and expose it as an external service:
|
||||
|
||||
<a name="kubectl-run"></a>
|
||||
|
||||
```shell
|
||||
$ kubectl run php-apache --image=gcr.io/google_containers/hpa-example --requests=cpu=200m
|
||||
replicationcontroller "php-apache" created
|
||||
|
||||
$ kubectl expose rc php-apache --port=80 --type=LoadBalancer
|
||||
service "php-apache" exposed
|
||||
|
||||
```
|
||||
Now, we will wait some time and verify that both the replication controller and the service were correctly created and are running. We will also determine the IP address of the service:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
php-apache-wa3t1 1/1 Running 0 12m
|
||||
|
||||
$ kubectl describe services php-apache | grep "LoadBalancer Ingress"
|
||||
LoadBalancer Ingress: 146.148.24.244
|
||||
|
||||
```
|
||||
We may now check that php-apache server works correctly by calling ``curl`` with the service's IP:
|
||||
|
||||
```shell
|
||||
$ curl http://146.148.24.244
|
||||
OK!
|
||||
|
||||
```
|
||||
Please notice that when exposing the service we assumed that our cluster runs on a provider which supports load balancers (e.g.: on GCE).
|
||||
If load balancers are not supported (e.g.: on Vagrant), we can expose php-apache service as ``ClusterIP`` and connect to it using the proxy on the master:
|
||||
|
||||
```shell
|
||||
$ kubectl expose rc php-apache --port=80 --type=ClusterIP
|
||||
service "php-apache" exposed
|
||||
|
||||
$ kubectl cluster-info | grep master
|
||||
Kubernetes master is running at https://146.148.6.215
|
||||
|
||||
$ curl -k -u <admin>:<password> https://146.148.6.215/api/v1/proxy/namespaces/default/services/php-apache/
|
||||
OK!
|
||||
|
||||
```
|
||||
## Step Two: Create horizontal pod autoscaler
|
||||
|
||||
Now that the server is running, we will create a horizontal pod autoscaler for it.
|
||||
To create it, we will use the [hpa-php-apache.yaml](hpa-php-apache.yaml) file, which looks like this:
|
||||
|
||||
```yaml
|
||||
apiVersion: extensions/v1beta1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: php-apache
|
||||
namespace: default
|
||||
spec:
|
||||
scaleRef:
|
||||
kind: ReplicationController
|
||||
name: php-apache
|
||||
namespace: default
|
||||
minReplicas: 1
|
||||
maxReplicas: 10
|
||||
cpuUtilization:
|
||||
targetPercentage: 50
|
||||
|
||||
```
|
||||
This defines a horizontal pod autoscaler that maintains between 1 and 10 replicas of the Pods
|
||||
controlled by the php-apache replication controller we created in the first step of these instructions.
|
||||
Roughly speaking, the horizontal autoscaler will increase and decrease the number of replicas
|
||||
(via the replication controller) so as to maintain an average CPU utilization across all Pods of 50%
|
||||
(since each pod requests 200 milli-cores by [kubectl run](#kubectl-run), this means average CPU utilization of 100 milli-cores).
|
||||
See [here](https://github.com/kubernetes/kubernetes/blob/master/docs/design/horizontal-pod-autoscaler/#autoscaling-algorithm) for more details on the algorithm.
|
||||
|
||||
We will create the autoscaler by executing the following command:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/horizontal-pod-autoscaling/hpa-php-apache.yaml
|
||||
horizontalpodautoscaler "php-apache" created
|
||||
|
||||
```
|
||||
Alternatively, we can create the autoscaler using [kubectl autoscale](../kubectl/kubectl_autoscale).
|
||||
The following command will create the equivalent autoscaler as defined in the [hpa-php-apache.yaml](hpa-php-apache.yaml) file:
|
||||
|
||||
```
|
||||
$ kubectl autoscale rc php-apache --cpu-percent=50 --min=1 --max=10
|
||||
replicationcontroller "php-apache" autoscaled
|
||||
|
||||
```
|
||||
We may check the current status of autoscaler by running:
|
||||
|
||||
```shell
|
||||
$ kubectl get hpa
|
||||
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE
|
||||
php-apache ReplicationController/default/php-apache/ 50% 0% 1 10 27s
|
||||
|
||||
```
|
||||
Please note that the current CPU consumption is 0% as we are not sending any requests to the server
|
||||
(the ``CURRENT`` column shows the average across all the pods controlled by the corresponding replication controller).
|
||||
|
||||
## Step Three: Increase load
|
||||
|
||||
Now, we will see how the autoscaler reacts on the increased load of the server.
|
||||
We will start an infinite loop of queries to our server (please run it in a different terminal):
|
||||
|
||||
```shell
|
||||
$ while true; do curl http://146.148.6.244; done
|
||||
|
||||
```
|
||||
We may examine, how CPU load was increased (the results should be visible after about 3-4 minutes) by executing:
|
||||
|
||||
```shell
|
||||
$ kubectl get hpa
|
||||
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE
|
||||
php-apache ReplicationController/default/php-apache/ 50% 305% 1 10 4m
|
||||
|
||||
```
|
||||
In the case presented here, it bumped CPU consumption to 305% of the request.
|
||||
As a result, the replication controller was resized to 7 replicas:
|
||||
|
||||
```shell
|
||||
$ kubectl get rc
|
||||
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS AGE
|
||||
php-apache php-apache gcr.io/google_containers/hpa-example run=php-apache 7 18m
|
||||
|
||||
```
|
||||
Now, we may increase the load even more by running yet another infinite loop of queries (in yet another terminal):
|
||||
|
||||
```shell
|
||||
$ while true; do curl http://146.148.6.244; done
|
||||
|
||||
```
|
||||
In the case presented here, it increased the number of serving pods to 10:
|
||||
|
||||
```shell
|
||||
$ kubectl get hpa
|
||||
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE
|
||||
php-apache ReplicationController/default/php-apache/ 50% 65% 1 10 14m
|
||||
|
||||
$ kubectl get rc
|
||||
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS AGE
|
||||
php-apache php-apache gcr.io/google_containers/hpa-example run=php-apache 10 24m
|
||||
|
||||
```
|
||||
## Step Four: Stop load
|
||||
|
||||
We will finish our example by stopping the user load.
|
||||
We will terminate both infinite ``while`` loops sending requests to the server and verify the result state:
|
||||
|
||||
```shell
|
||||
$ kubectl get hpa
|
||||
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE
|
||||
php-apache ReplicationController/default/php-apache/ 50% 0% 1 10 21m
|
||||
|
||||
$ kubectl get rc
|
||||
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS AGE
|
||||
php-apache php-apache gcr.io/google_containers/hpa-example run=php-apache 1 31m
|
||||
|
||||
```
|
||||
As we see, in the presented case CPU utilization dropped to 0, and the number of replicas dropped to 1.
|
||||
|
||||
|
||||
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
title: "Checking Pod Health"
|
||||
---
|
||||
|
||||
This example shows two types of pod [health checks](../production-pods/#liveness-and-readiness-probes-aka-health-checks): HTTP checks and container execution checks.
|
||||
|
||||
The [exec-liveness.yaml](exec-liveness.yaml) demonstrates the container execution check.
|
||||
|
||||
```yaml
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- cat
|
||||
- /tmp/health
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 1
|
||||
|
||||
```
|
||||
Kubelet executes the command `cat /tmp/health` in the container and reports failure if the command returns a non-zero exit code.
|
||||
|
||||
Note that the container removes the `/tmp/health` file after 10 seconds,
|
||||
|
||||
```shell
|
||||
echo ok > /tmp/health; sleep 10; rm -rf /tmp/health; sleep 600
|
||||
|
||||
```
|
||||
so when Kubelet executes the health check 15 seconds (defined by initialDelaySeconds) after the container started, the check would fail.
|
||||
|
||||
|
||||
The [http-liveness.yaml](http-liveness.yaml) demonstrates the HTTP check.
|
||||
|
||||
```yaml
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /healthz
|
||||
port: 8080
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 1
|
||||
|
||||
```
|
||||
The Kubelet sends an HTTP request to the specified path and port to perform the health check. If you take a look at image/server.go, you will see the server starts to respond with an error code 500 after 10 seconds, so the check fails. The Kubelet sends the probe to the container's ip address by default which could be specified with `host` as part of httpGet probe. If the container listens on `127.0.0.1`, `host` should be specified as `127.0.0.1`. In general, if the container listens on its ip address or on all interfaces (0.0.0.0), there is no need to specify the `host` as part of the httpGet probe.
|
||||
|
||||
This [guide](../walkthrough/k8s201/#health-checking) has more information on health checks.
|
||||
|
||||
## Get your hands dirty
|
||||
|
||||
To show the health check is actually working, first create the pods:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/liveness/exec-liveness.yaml
|
||||
$ kubectl create -f docs/user-guide/liveness/http-liveness.yaml
|
||||
|
||||
```
|
||||
Check the status of the pods once they are created:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
[...]
|
||||
liveness-exec 1/1 Running 0 13s
|
||||
liveness-http 1/1 Running 0 13s
|
||||
|
||||
```
|
||||
Check the status half a minute later, you will see the container restart count being incremented:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
[...]
|
||||
liveness-exec 1/1 Running 1 36s
|
||||
liveness-http 1/1 Running 1 36s
|
||||
|
||||
```
|
||||
At the bottom of the *kubectl describe* output there are messages indicating that the liveness probes have failed, and the containers have been killed and recreated.
|
||||
|
||||
```shell
|
||||
$ kubectl describe pods liveness-exec
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: "Elasticsearch/Kibana Logging Demonstration"
|
||||
---
|
||||
This directory contains two [pod](/{{page.version}}/docs/user-guide/pods) specifications which can be used as synthetic
|
||||
logging sources. The pod specification in [synthetic_0_25lps.yaml](synthetic_0_25lps.yaml)
|
||||
describes a pod that just emits a log message once every 4 seconds. The pod specification in
|
||||
[synthetic_10lps.yaml](synthetic_10lps.yaml)
|
||||
describes a pod that just emits 10 log lines per second.
|
||||
|
||||
See [logging document](../logging) for more details about logging. To observe the ingested log lines when using Google Cloud Logging please see the getting
|
||||
started instructions
|
||||
at [Cluster Level Logging to Google Cloud Logging](/{{page.version}}/docs/getting-started-guides/logging).
|
||||
To observe the ingested log lines when using Elasticsearch and Kibana please see the getting
|
||||
started instructions
|
||||
at [Cluster Level Logging with Elasticsearch and Kibana](/{{page.version}}/docs/getting-started-guides/logging-elasticsearch).
|
||||
|
||||
|
||||
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
title: "Node selection example"
|
||||
---
|
||||
This example shows how to assign a [pod](../pods) to a specific [node](/{{page.version}}/docs/admin/node) or to one of a set of nodes using node labels and the nodeSelector field in a pod specification. Generally this is unnecessary, as the scheduler will take care of things for you, but you may want to do so in certain circumstances like to ensure that your pod ends up on a machine with an SSD attached to it.
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
|
||||
This example assumes that you have a basic understanding of Kubernetes pods and that you have [turned up a Kubernetes cluster](https://github.com/kubernetes/kubernetes#documentation).
|
||||
|
||||
### Step One: Attach label to the node
|
||||
|
||||
Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the one that you want to add a label to.
|
||||
|
||||
Then, to add a label to the node you've chosen, run `kubectl label nodes <node-name> <label-key>=<label-value>`. For example, if my node name is 'kubernetes-foo-node-1.c.a-robinson.internal' and my desired label is 'disktype=ssd', then I can run `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`.
|
||||
|
||||
If this fails with an "invalid command" error, you're likely using an older version of kubectl that doesn't have the `label` command. In that case, see the [previous version](https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) of this guide for instructions on how to manually set labels on a node.
|
||||
|
||||
Also, note that label keys must be in the form of DNS labels (as described in the [identifiers doc](https://github.com/kubernetes/kubernetes/blob/master/docs/design/identifiers)), meaning that they are not allowed to contain any upper-case letters.
|
||||
|
||||
You can verify that it worked by re-running `kubectl get nodes` and checking that the node now has a label.
|
||||
|
||||
### Step Two: Add a nodeSelector field to your pod configuration
|
||||
|
||||
Take whatever pod config file you want to run, and add a nodeSelector section to it, like this. For example, if this is my pod config:
|
||||
|
||||
<pre>
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
env: test
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
</pre>
|
||||
|
||||
Then add a nodeSelector like so:
|
||||
|
||||
<pre>
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
env: test
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
imagePullPolicy: IfNotPresent
|
||||
<b>nodeSelector:
|
||||
disktype: ssd</b>
|
||||
</pre>
|
||||
|
||||
When you then run `kubectl create -f pod.yaml`, the pod will get scheduled on the node that you attached the label to! You can verify that it worked by running `kubectl get pods -o wide` and looking at the "NODE" that the pod was assigned to.
|
||||
|
||||
### Conclusion
|
||||
|
||||
While this example only covered one node, you can attach labels to as many nodes as you want. Then when you schedule a pod with a nodeSelector, it can be scheduled on any of the nodes that satisfy that nodeSelector. Be careful that it will match at least one node, however, because if it doesn't the pod won't be scheduled at all.
|
||||
|
||||
|
||||
|
||||
@@ -1,98 +0,0 @@
|
||||
---
|
||||
title: "How To Use Persistent Volumes"
|
||||
---
|
||||
The purpose of this guide is to help you become familiar with [Kubernetes Persistent Volumes](../persistent-volumes). By the end of the guide, we'll have
|
||||
nginx serving content from your persistent volume.
|
||||
|
||||
This guide assumes knowledge of Kubernetes fundamentals and that you have a cluster up and running.
|
||||
|
||||
See [Persistent Storage design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/persistent-storage) for more information.
|
||||
|
||||
## Provisioning
|
||||
|
||||
A Persistent Volume (PV) in Kubernetes represents a real piece of underlying storage capacity in the infrastructure. Cluster administrators
|
||||
must first create storage (create their Google Compute Engine (GCE) disks, export their NFS shares, etc.) in order for Kubernetes to mount it.
|
||||
|
||||
PVs are intended for "network volumes" like GCE Persistent Disks, NFS shares, and AWS ElasticBlockStore volumes. `HostPath` was included
|
||||
for ease of development and testing. You'll create a local `HostPath` for this example.
|
||||
|
||||
> IMPORTANT! For `HostPath` to work, you will need to run a single node cluster. Kubernetes does not
|
||||
support local storage on the host at this time. There is no guarantee your pod ends up on the correct node where the `HostPath` resides.
|
||||
|
||||
|
||||
|
||||
```shell
|
||||
# This will be nginx's webroot
|
||||
$ mkdir /tmp/data01
|
||||
$ echo 'I love Kubernetes storage!' > /tmp/data01/index.html
|
||||
|
||||
```
|
||||
PVs are created by posting them to the API server.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/persistent-volumes/volumes/local-01.yaml
|
||||
NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON
|
||||
pv0001 type=local 10737418240 RWO Available
|
||||
|
||||
```
|
||||
## Requesting storage
|
||||
|
||||
Users of Kubernetes request persistent storage for their pods. They don't know how the underlying cluster is provisioned.
|
||||
They just know they can rely on their claim to storage and can manage its lifecycle independently from the many pods that may use it.
|
||||
|
||||
Claims must be created in the same namespace as the pods that use them.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/persistent-volumes/claims/claim-01.yaml
|
||||
|
||||
$ kubectl get pvc
|
||||
NAME LABELS STATUS VOLUME
|
||||
myclaim-1 map[]
|
||||
|
||||
|
||||
# A background process will attempt to match this claim to a volume.
|
||||
# The eventual state of your claim will look something like this:
|
||||
|
||||
$ kubectl get pvc
|
||||
NAME LABELS STATUS VOLUME
|
||||
myclaim-1 map[] Bound pv0001
|
||||
|
||||
$ kubectl get pv
|
||||
NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON
|
||||
pv0001 type=local 10737418240 RWO Bound default/myclaim-1
|
||||
|
||||
```
|
||||
## Using your claim as a volume
|
||||
|
||||
Claims are used as volumes in pods. Kubernetes uses the claim to look up its bound PV. The PV is then exposed to the pod.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/persistent-volumes/simpletest/pod.yaml
|
||||
|
||||
$ kubectl get pods
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
mypod 1/1 Running 0 1h
|
||||
|
||||
$ kubectl create -f docs/user-guide/persistent-volumes/simpletest/service.json
|
||||
$ kubectl get services
|
||||
NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE
|
||||
frontendservice 10.0.0.241 <none> 3000/TCP name=frontendhttp 1d
|
||||
kubernetes 10.0.0.2 <none> 443/TCP <none> 2d
|
||||
|
||||
```
|
||||
## Next steps
|
||||
|
||||
You should be able to query your service endpoint and see what content nginx is serving. A "forbidden" error might mean you
|
||||
need to disable SELinux (setenforce 0).
|
||||
|
||||
```shell
|
||||
$ curl 10.0.0.241:3000
|
||||
I love Kubernetes storage!
|
||||
|
||||
```
|
||||
Hopefully this simple guide is enough to get you started with PersistentVolumes. If you have any questions, join the team on [Slack](../../troubleshooting/#slack) and ask!
|
||||
|
||||
Enjoy!
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
title: "Resource Quota"
|
||||
---
|
||||
This page has been moved to [here](/{{page.version}}/docs/admin/resourcequota/)
|
||||
|
||||
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
title: "Secrets example"
|
||||
---
|
||||
Following this example, you will create a [secret](../secrets) and a [pod](../pods) that consumes that secret in a [volume](../volumes). See [Secrets design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/secrets) for more information.
|
||||
|
||||
## Step Zero: Prerequisites
|
||||
|
||||
This example assumes you have a Kubernetes cluster installed and running, and that you have
|
||||
installed the `kubectl` command line tool somewhere in your path. Please see the [getting
|
||||
started](/{{page.version}}/docs/getting-started-guides/) for installation instructions for your platform.
|
||||
|
||||
## Step One: Create the secret
|
||||
|
||||
A secret contains a set of named byte arrays.
|
||||
|
||||
Use the [`examples/secrets/secret.yaml`](secret.yaml) file to create a secret:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/secrets/secret.yaml
|
||||
|
||||
```
|
||||
You can use `kubectl` to see information about the secret:
|
||||
|
||||
```shell
|
||||
$ kubectl get secrets
|
||||
NAME TYPE DATA
|
||||
test-secret Opaque 2
|
||||
|
||||
$ kubectl describe secret test-secret
|
||||
Name: test-secret
|
||||
Labels: <none>
|
||||
Annotations: <none>
|
||||
|
||||
Type: Opaque
|
||||
|
||||
Data
|
||||
====
|
||||
data-1: 9 bytes
|
||||
data-2: 11 bytes
|
||||
|
||||
```
|
||||
## Step Two: Create a pod that consumes a secret
|
||||
|
||||
Pods consume secrets in volumes. Now that you have created a secret, you can create a pod that
|
||||
consumes it.
|
||||
|
||||
Use the [`examples/secrets/secret-pod.yaml`](secret-pod.yaml) file to create a Pod that consumes the secret.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/secrets/secret-pod.yaml
|
||||
|
||||
```
|
||||
This pod runs a binary that displays the content of one of the pieces of secret data in the secret
|
||||
volume:
|
||||
|
||||
```shell
|
||||
$ kubectl logs secret-test-pod
|
||||
2015-04-29T21:17:24.712206409Z content of file "/etc/secret-volume/data-1": value-1
|
||||
|
||||
```
|
||||
@@ -1,122 +0,0 @@
|
||||
---
|
||||
title: "Rolling update example"
|
||||
---
|
||||
|
||||
<!--
|
||||
Copyright 2014 Google Inc. All rights reserved.
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
|
||||
-->
|
||||
|
||||
# Rolling update example
|
||||
|
||||
This example demonstrates the usage of Kubernetes to perform a [rolling update](../kubectl/kubectl_rolling-update) on a running group of [pods](/{{page.version}}/docs/user-guide/pods). See [here](../managing-deployments/#updating-your-application-without-a-service-outage) to understand why you need a rolling update. Also check [rolling update design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/simple-rolling-update) for more information.
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
|
||||
This example assumes that you have forked the repository and [turned up a Kubernetes cluster](/{{page.version}}/docs/getting-started-guides/):
|
||||
|
||||
```shell
|
||||
$ cd kubernetes
|
||||
$ ./cluster/kube-up.sh
|
||||
|
||||
```
|
||||
### Step One: Turn up the UX for the demo
|
||||
|
||||
You can use bash job control to run this in the background (note that you must use the default port -- 8001 -- for the following demonstration to work properly).
|
||||
This can sometimes spew to the output so you could also run it in a different terminal. You have to run `kubectl proxy` in the root of the
|
||||
Kubernetes repository. Otherwise you will get "404 page not found" errors as the paths will not match. You can find more information about `kubectl proxy`
|
||||
[here](/{{page.version}}/docs/user-guide/kubectl/kubectl_proxy).
|
||||
|
||||
```shell
|
||||
$ kubectl proxy --www=docs/user-guide/update-demo/local/ &
|
||||
I0218 15:18:31.623279 67480 proxy.go:36] Starting to serve on localhost:8001
|
||||
|
||||
```
|
||||
Now visit the the [demo website](http://localhost:8001/static). You won't see anything much quite yet.
|
||||
|
||||
### Step Two: Run the replication controller
|
||||
|
||||
Now we will turn up two replicas of an [image](../images). They all serve on internal port 80.
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/update-demo/nautilus-rc.yaml
|
||||
|
||||
```
|
||||
After pulling the image from the Docker Hub to your worker nodes (which may take a minute or so) you'll see a couple of squares in the UI detailing the pods that are running along with the image that they are serving up. A cute little nautilus.
|
||||
|
||||
### Step Three: Try scaling the replication controller
|
||||
|
||||
Now we will increase the number of replicas from two to four:
|
||||
|
||||
```shell
|
||||
$ kubectl scale rc update-demo-nautilus --replicas=4
|
||||
|
||||
```
|
||||
If you go back to the [demo website](http://localhost:8001/static/index) you should eventually see four boxes, one for each pod.
|
||||
|
||||
### Step Four: Update the docker image
|
||||
|
||||
We will now update the docker image to serve a different image by doing a rolling update to a new Docker image.
|
||||
|
||||
```shell
|
||||
$ kubectl rolling-update update-demo-nautilus --update-period=10s -f docs/user-guide/update-demo/kitten-rc.yaml
|
||||
|
||||
```
|
||||
The rolling-update command in kubectl will do 2 things:
|
||||
|
||||
1. Create a new [replication controller](/{{page.version}}/docs/user-guide/replication-controller) with a pod template that uses the new image (`gcr.io/google_containers/update-demo:kitten`)
|
||||
2. Scale the old and new replication controllers until the new controller replaces the old. This will kill the current pods one at a time, spinning up new ones to replace them.
|
||||
|
||||
Watch the [demo website](http://localhost:8001/static/index), it will update one pod every 10 seconds until all of the pods have the new image.
|
||||
Note that the new replication controller definition does not include the replica count, so the current replica count of the old replication controller is preserved.
|
||||
But if the replica count had been specified, the final replica count of the new replication controller will be equal this number.
|
||||
|
||||
### Step Five: Bring down the pods
|
||||
|
||||
```shell
|
||||
$ kubectl delete rc update-demo-kitten
|
||||
|
||||
```
|
||||
This first stops the replication controller by turning the target number of replicas to 0 and then deletes the controller.
|
||||
|
||||
### Step Six: Cleanup
|
||||
|
||||
To turn down a Kubernetes cluster:
|
||||
|
||||
```shell
|
||||
$ ./cluster/kube-down.sh
|
||||
|
||||
```
|
||||
Kill the proxy running in the background:
|
||||
After you are done running this demo make sure to kill it:
|
||||
|
||||
```shell
|
||||
$ jobs
|
||||
[1]+ Running ./kubectl proxy --www=local/ &
|
||||
$ kill %1
|
||||
[1]+ Terminated: 15 ./kubectl proxy --www=local/
|
||||
|
||||
```
|
||||
### Updating the Docker images
|
||||
|
||||
If you want to build your own docker images, you can set `$DOCKER_HUB_USER` to your Docker user id and run the included shell script. It can take a few minutes to download/upload stuff.
|
||||
|
||||
```shell
|
||||
$ export DOCKER_HUB_USER=my-docker-id
|
||||
$ ./docs/user-guide/update-demo/build-images.sh
|
||||
|
||||
```
|
||||
To use your custom docker image in the above examples, you will need to change the image name in `docs/user-guide/update-demo/nautilus-rc.yaml` and `docs/user-guide/update-demo/kitten-rc.yaml`.
|
||||
|
||||
@@ -1,174 +0,0 @@
|
||||
---
|
||||
title: "Kubernetes 101 - Kubectl CLI and Pods"
|
||||
---
|
||||
|
||||
For Kubernetes 101, we will cover kubectl, pods, volumes, and multiple containers
|
||||
|
||||
In order for the kubectl usage examples to work, make sure you have an examples directory locally, either from [a release](https://github.com/kubernetes/kubernetes/releases) or [the source](https://github.com/kubernetes/kubernetes).
|
||||
|
||||
|
||||
|
||||
* TOC
|
||||
{:toc}
|
||||
|
||||
## Kubectl CLI
|
||||
|
||||
The easiest way to interact with Kubernetes is via the [kubectl](../kubectl/kubectl) command-line interface.
|
||||
|
||||
For more info about kubectl, including its usage, commands, and parameters, see the [kubectl CLI reference](../kubectl/kubectl).
|
||||
|
||||
If you haven't installed and configured kubectl, finish the [prerequisites](../prereqs) before continuing.
|
||||
|
||||
## Pods
|
||||
|
||||
In Kubernetes, a group of one or more containers is called a _pod_. Containers in a pod are deployed together, and are started, stopped, and replicated as a group.
|
||||
|
||||
See [pods](/{{page.version}}/docs/user-guide/pods) for more details.
|
||||
|
||||
|
||||
#### Pod Definition
|
||||
|
||||
The simplest pod definition describes the deployment of a single container. For example, an nginx web server pod might be defined as such:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
A pod definition is a declaration of a _desired state_. Desired state is a very important concept in the Kubernetes model. Many things present a desired state to the system, and it is Kubernetes' responsibility to make sure that the current state matches the desired state. For example, when you create a Pod, you declare that you want the containers in it to be running. If the containers happen to not be running (e.g. program failure, ...), Kubernetes will continue to (re-)create them for you in order to drive them to the desired state. This process continues until the Pod is deleted.
|
||||
|
||||
See the [design document](https://github.com/kubernetes/kubernetes/tree/master/docs/design/) for more details.
|
||||
|
||||
|
||||
#### Pod Management
|
||||
|
||||
Create a pod containing an nginx server ([pod-nginx.yaml](pod-nginx.yaml)):
|
||||
|
||||
```shell
|
||||
$ kubectl create -f docs/user-guide/walkthrough/pod-nginx.yaml
|
||||
```
|
||||
List all pods:
|
||||
|
||||
```shell
|
||||
$ kubectl get pods
|
||||
```
|
||||
On most providers, the pod IPs are not externally accessible. The easiest way to test that the pod is working is to create a busybox pod and exec commands on it remotely. See the [command execution documentation](../kubectl/kubectl_exec) for details.
|
||||
|
||||
Provided the pod IP is accessible, you should be able to access its http endpoint with curl on port 80:
|
||||
|
||||
```shell
|
||||
$ curl http://$(kubectl get pod nginx -o go-template={{.status.podIP}})
|
||||
```
|
||||
Delete the pod by name:
|
||||
|
||||
```shell
|
||||
$ kubectl delete pod nginx
|
||||
```
|
||||
#### Volumes
|
||||
|
||||
That's great for a simple static web server, but what about persistent storage?
|
||||
|
||||
The container file system only lives as long as the container does. So if your app's state needs to survive relocation, reboots, and crashes, you'll need to configure some persistent storage.
|
||||
|
||||
For this example we'll be creating a Redis pod with a named volume and volume mount that defines the path to mount the volume.
|
||||
|
||||
1. Define a volume:
|
||||
|
||||
```yaml
|
||||
volumes:
|
||||
- name: redis-persistent-storage
|
||||
emptyDir: {}
|
||||
```
|
||||
2. Define a volume mount within a container definition:
|
||||
|
||||
```yaml
|
||||
volumeMounts:
|
||||
# name must match the volume name below
|
||||
- name: redis-persistent-storage
|
||||
# mount path within the container
|
||||
mountPath: /data/redis
|
||||
```
|
||||
Example Redis pod definition with a persistent storage volume ([pod-redis.yaml](pod-redis.yaml)):
|
||||
|
||||
<!-- BEGIN MUNGE: EXAMPLE pod-redis.yaml -->
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: redis
|
||||
spec:
|
||||
containers:
|
||||
- name: redis
|
||||
image: redis
|
||||
volumeMounts:
|
||||
- name: redis-persistent-storage
|
||||
mountPath: /data/redis
|
||||
volumes:
|
||||
- name: redis-persistent-storage
|
||||
emptyDir: {}
|
||||
```
|
||||
[Download example](pod-redis.yaml)
|
||||
<!-- END MUNGE: EXAMPLE pod-redis.yaml -->
|
||||
|
||||
Notes:
|
||||
- The volume mount name is a reference to a specific empty dir volume.
|
||||
- The volume mount path is the path to mount the empty dir volume within the container.
|
||||
|
||||
##### Volume Types
|
||||
|
||||
- **EmptyDir**: Creates a new directory that will persist across container failures and restarts.
|
||||
- **HostPath**: Mounts an existing directory on the node's file system (e.g. `/var/logs`).
|
||||
|
||||
See [volumes](/{{page.version}}/docs/user-guide/volumes) for more details.
|
||||
|
||||
|
||||
#### Multiple Containers
|
||||
|
||||
_Note:
|
||||
The examples below are syntactically correct, but some of the images (e.g. kubernetes/git-monitor) don't exist yet. We're working on turning these into working examples._
|
||||
|
||||
|
||||
However, often you want to have two different containers that work together. An example of this would be a web server, and a helper job that polls a git repository for new updates:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: www
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
volumeMounts:
|
||||
- mountPath: /srv/www
|
||||
name: www-data
|
||||
readOnly: true
|
||||
- name: git-monitor
|
||||
image: kubernetes/git-monitor
|
||||
env:
|
||||
- name: GIT_REPO
|
||||
value: http://github.com/some/repo.git
|
||||
volumeMounts:
|
||||
- mountPath: /data
|
||||
name: www-data
|
||||
volumes:
|
||||
- name: www-data
|
||||
emptyDir: {}
|
||||
```
|
||||
Note that we have also added a volume here. In this case, the volume is mounted into both containers. It is marked `readOnly` in the web server's case, since it doesn't need to write to the directory.
|
||||
|
||||
Finally, we have also introduced an environment variable to the `git-monitor` container, which allows us to parameterize that container with the particular git repository that we want to track.
|
||||
|
||||
|
||||
## What's Next?
|
||||
|
||||
Continue on to [Kubernetes 201](k8s201) or
|
||||
for a complete application see the [guestbook example](https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook/)
|
||||
Reference in New Issue
Block a user