Merge branch 'master' into release-1.8

This commit is contained in:
steveperry-53
2017-08-09 10:17:40 -07:00
25 changed files with 195 additions and 103 deletions
+3 -6
View File
@@ -1,6 +1,3 @@
approvers: reviewers:
- smarterclayton - chenopis
- janetkuo - zacharysarah
- pwittrock
- kelseyhightower
- jaredbhatti
+4 -2
View File
@@ -29,8 +29,11 @@ toc:
section: section:
- docs/tutorials/kubernetes-basics/update-intro.html - docs/tutorials/kubernetes-basics/update-intro.html
- docs/tutorials/kubernetes-basics/update-interactive.html - docs/tutorials/kubernetes-basics/update-interactive.html
- title: Online Training Course - title: Online Training Courses
section: Scalable Microservices with Kubernetes (Udacity)
path: https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615 path: https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615
section: Introduction to Kubernetes (edX)
path: https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#
- docs/tutorials/stateless-application/hello-minikube.md - docs/tutorials/stateless-application/hello-minikube.md
- title: Configuration - title: Configuration
section: section:
@@ -61,4 +64,3 @@ toc:
- title: Services - title: Services
section: section:
- docs/tutorials/services/source-ip.md - docs/tutorials/services/source-ip.md
@@ -77,7 +77,7 @@ To verify this connection, use the `--kubelet-certificate-authority` flag to
provide the apiserver with a root certificates bundle to use to verify the provide the apiserver with a root certificates bundle to use to verify the
kubelet's serving certificate. kubelet's serving certificate.
If that is not possible, use [SSH tunneling](/docs/admin/master-node-communication/#ssh-tunnels) If that is not possible, use [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels)
between the apiserver and kubelet if required to avoid connecting over an between the apiserver and kubelet if required to avoid connecting over an
untrusted or public network. untrusted or public network.
@@ -82,7 +82,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN).
## Not All Objects are in a Namespace ## Not All Objects are in a Namespace
Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are
in some namespace. However namespace resources are not themselves in a namespace. in some namespaces. However namespace resources are not themselves in a namespace.
And low-level resources, such as [nodes](/docs/admin/node) and And low-level resources, such as [nodes](/docs/admin/node) and
persistentVolumes, are not in any namespace. Events are an exception: they may or may not persistentVolumes, are not in any namespace. Events are an exception: they may or may not
have a namespace, depending on the object the event is about. have a namespace, depending on the object the event is about.
@@ -101,7 +101,7 @@ Kubernetes supports 2 primary modes of finding a Service - environment variables
### Environment Variables ### Environment Variables
When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx pods (your pod name will be different): When a Pod runs on a Node, the kubelet adds a set of environment variables for each active Service. This introduces an ordering problem. To see why, inspect the environment of your running nginx pods (your pod name will be different):
```shell ```shell
$ kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE $ kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
@@ -93,7 +93,7 @@ Normally, the machine that a pod runs on is selected by the Kubernetes scheduler
created by the Daemon controller have the machine already selected (`.spec.nodeName` is specified created by the Daemon controller have the machine already selected (`.spec.nodeName` is specified
when the pod is created, so it is ignored by the scheduler). Therefore: when the pod is created, so it is ignored by the scheduler). Therefore:
- the [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected - The [`unschedulable`](/docs/admin/node/#manual-node-administration) field of a node is not respected
by the DaemonSet controller. by the DaemonSet controller.
- DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster - DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster
bootstrap. bootstrap.
@@ -94,10 +94,9 @@ spec:
volumeClaimTemplates: volumeClaimTemplates:
- metadata: - metadata:
name: www name: www
annotations:
volume.beta.kubernetes.io/storage-class: anything
spec: spec:
accessModes: [ "ReadWriteOnce" ] accessModes: [ "ReadWriteOnce" ]
storageClassName: my-storage-class
resources: resources:
requests: requests:
storage: 1Gi storage: 1Gi
@@ -143,7 +142,8 @@ Note that Cluster Domain will be set to `cluster.local` unless
Kubernetes creates one [PersistentVolume](/docs/concepts/storage/volumes/) for each Kubernetes creates one [PersistentVolume](/docs/concepts/storage/volumes/) for each
VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume
with a storage class of `anything` and 1 Gib of provisioned storage. When a Pod is (re)scheduled with a StorageClass of `my-storage-class` and 1 Gib of provisioned storage. If no StorageClass
is specified, then the default StorageClass will be used. When a Pod is (re)scheduled
onto a node, its `volumeMounts` mount the PersistentVolumes associated with its onto a node, its `volumeMounts` mount the PersistentVolumes associated with its
PersistentVolume Claims. Note that, the PersistentVolumes associated with the PersistentVolume Claims. Note that, the PersistentVolumes associated with the
Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted. Pods' PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted.
@@ -83,7 +83,7 @@ Here are some ideas for how to use Init Containers:
* Wait for some time before starting the app Container with a command like `sleep 60`. * Wait for some time before starting the app Container with a command like `sleep 60`.
* Clone a git repository into a volume. * Clone a git repository into a volume.
* Place values into a configuration file and run a template tool to dynamically * Place values into a configuration file and run a template tool to dynamically
generate a configuration file for the the main app Container. For example, generate a configuration file for the main app Container. For example,
place the POD_IP value in a configuration and generate the main app place the POD_IP value in a configuration and generate the main app
configuration file using Jinja. configuration file using Jinja.
+70 -62
View File
@@ -4,94 +4,102 @@ title: Installing Kubernetes On-premises/Cloud Providers with Kubespray
## Overview ## Overview
This quickstart helps to install a Kubernetes cluster hosted This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, or Baremetal with [Kubespray](https://github.com/kubernetes-incubator/kubespray).
on GCE, Azure, OpenStack, AWS or Baremetal with
[`Kubespray`](https://github.com/kubernetes-incubator/kubespray) tool.
Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides:
[inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md)
generation CLI tools and domain knowledge for generic OS/Kubernetes
clusters configuration management tasks. It provides:
* [High available cluster](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ha-mode.md) * a highly available cluster
* [Composable](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/vars.md) * composable attributes
(Choice of the network plugin, for instance) * support for most popular Linux distributions
* Support most popular Linux * continuous integration tests
[distributions](https://github.com/kubernetes-incubator/kubespray#supported-linux-distributions)
* Continuous integration tests
To choose a tool which fits your use case the best, you may want to read this To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md) to [kubeadm](../kubeadm) and [kops](../kops).
[comparison](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md)
to [kubeadm](../kubeadm) and [kops](../kops).
## Creating a cluster ## Creating a cluster
### (1/4) Ensure the underlay [requirements](https://github.com/kubernetes-incubator/kubespray#requirements) are met ### (1/5) Meet the underlay [requirements](https://github.com/kubernetes-incubator/kubespray#requirements)
#### Checklist Provision servers with the following requirements:
* You must have cloud instances or baremetal nodes running for your future Kubernetes cluster. * `Ansible v2.3` (or newer)
A way to achieve that is to use the * `Jinja 2.9` (or newer)
[kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md). * `python-netaddr` installed on the machine that running Ansible commands
* Or provision baremetal hosts with a tool-of-your-choice or launch cloud instances, * Target servers must have access to the Internet in order to pull docker images
then create an inventory file for Ansible with this [tool](https://github.com/kubernetes-incubator/kubespray/blob/master/contrib/inventory_builder/inventory.py). * Target servers are configured to allow IPv4 forwarding
* Target servers have SSH connectivity ( tcp/22 ) directly to your nodes or through a bastion host/ssh jump box
* Target servers have a privileged user
* Your SSH key must be copied to all the servers that are part of your inventory
* Firewall rules configured properly to allow Ansible and Kubernetes components to communicate
* If using a cloud provider, you must have the appropriate credentials available and exported as environment variables
### (2/4) Compose the deployment Kubespray provides the following utilities to help provision your environment:
#### Checklist * [Terraform](https://www.terraform.io/) scripts for the following cloud providers:
* [AWS](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws)
* [OpenStack](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib/terraform/aws)
* [kubespray-cli](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md)
* Customize your deployment by usual Ansible meanings, which is **Note:** kubespray-cli is no longer actively maintained.
[generating inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory) {. :note}
and overriding default data [variables](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/vars.md).
Or just stick with default values (Kubespray will choose Calico networking plugin for you
then). This includes steps like deciding on the:
* DNS [configuration options](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/dns-stack.md)
* [Networking plugin](https://github.com/kubernetes-incubator/kubespray#network-plugins) to use
* [Versions](https://github.com/kubernetes-incubator/kubespray#versions-of-supported-components)
of components.
* Additional node groups like [bastion hosts](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md#bastion-host) or
[Calico BGP route reflectors](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/calico.md#optional--bgp-peering-with-border-routers).
* Plan custom deployment steps, if any, or use the default composition layer in the
[cluster definition file](https://github.com/kubernetes-incubator/kubespray/blob/master/cluster.yml).
Taking the best from Ansible world, Kubespray allows users to execute arbitrary steps via the
``ansible-playbook`` with given inventory, playbooks, data overrides and tags, limits, batches
of nodes to deploy and so on.
* For large deployments (100+ nodes), you may want to
[tweak things](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md)
for best results.
### (3/4) Run the deployment ### (2/5) Compose an inventory file
#### Checklist After you provision your servers, create an [inventory file for Ansible](http://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)".
* Apply deployment with ### (3/5) Plan your cluster deployment
[kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md)
or ``ansible-playbook``
[manual commands](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
### (4/4) (Optional) verify inter-pods connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md) Kubespray provides the ability to customize many aspects of the deployment:
#### Checklist * CNI (networking) plugins
* DNS configuration
* Choice of control plane: native/binary or containerized with docker or rkt)
* Component versions
* Calico route reflectors
* Component runtime options
* Certificate generation methods
* Ensure the netchecker-agent's pods can resolve DNS requests and ping each over within the default namespace. Kubespray customizations can be made to a [variable file](http://docs.ansible.com/ansible/playbooks_variables.html). If you are just getting started with Kubespray, consider using the Kubespray defaults to deploy your cluster and explore Kubernetes.
Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
## Explore contributed add-ons ### (4/5) Deploy a Cluster
See the [list of contributed playbooks](https://github.com/kubernetes-incubator/kubespray/tree/master/contrib) Next, deploy your cluster with one of two methods:
to explore other deployment options.
* [ansible-playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment).
* [kubespray-cli tool](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md)
**Note:** kubespray-cli is no longer actively maintained.
{. :note}
Both methods run the default [cluster definition file](https://github.com/kubernetes-incubator/kubespray/blob/master/cluster.yml).
Large deployments (100+ nodes) may require [specific adjustments](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/large-deployments.md) for best results.
### (5/5) Verify the deployment
Kubespray provides a way to verify inter-pod connectivity and DNS resolve with [Netchecker](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/netcheck.md). Netchecker ensures the netchecker-agents pods can resolve DNS requests and ping each over within the default namespace. Those pods mimic similar behavior of the rest of the workloads and serve as cluster health indicators.
## Cluster operations
Kubespray provides additional playbooks to manage your cluster: _scale_ and _upgrade_.
### Scale your cluster
You can scale your cluster by running the scale playbook. For more information, see "[Adding nodes](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#Adding-nodes)".
### Upgrade your cluster
You can upgrade your cluster by running the upgrade-cluster playbook. For more information, see "[Upgrades](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/upgrades.md)".
## What's next ## What's next
Kubespray has quite a few [marks on the radar](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md). Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/roadmap.md).
## Cleanup ## Cleanup
To delete your scratch cluster, you can apply the You can reset your nodes and wipe out all components installed with Kubespray via the [reset playbook](https://github.com/kubernetes-incubator/kubespray/blob/master/reset.yml).
[reset role](https://github.com/kubernetes-incubator/kubespray/blob/master/roles/reset/tasks/main.yml)
with the manual ``ansible-playbook`` command.
Note, that it is highly unrecommended to delete production clusters with the reset playbook! **Caution:** When running the reset playbook, be sure not to accidentally target your production cluster!
{. :caution}
## Feedback ## Feedback
+6 -3
View File
@@ -228,13 +228,16 @@ Note that we have passed these two values already as parameter to the apiserver
A template for a replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/kubedns-controller.yaml.in][12] in the repository. The following steps are necessary in order to get a valid replication controller yaml file: A template for a replication controller spinning up the pod with the 3 containers can be found at [cluster/addons/dns/kubedns-controller.yaml.in][12] in the repository. The following steps are necessary in order to get a valid replication controller yaml file:
- replace `{% raw %}{{ pillar['dns_replicas'] }}{% endraw %}` with `1` {% assign dns_replicas = "{{ pillar['dns_replicas'] }}" %}
- replace `{% raw %}{{ pillar['dns_domain'] }}{% endraw %}` with `cluster.local.` {% assign dns_domain = "{{ pillar['dns_domain'] }}" %}
- replace `{{ dns_replicas }}` with `1`
- replace `{{ dns_domain }}` with `cluster.local.`
- add `--kube_master_url=${KUBERNETES_MASTER}` parameter to the kube2sky container command. - add `--kube_master_url=${KUBERNETES_MASTER}` parameter to the kube2sky container command.
In addition the service template at [cluster/addons/dns/kubedns-controller.yaml.in][12] needs the following replacement: In addition the service template at [cluster/addons/dns/kubedns-controller.yaml.in][12] needs the following replacement:
- `{% raw %}{{ pillar['dns_server'] }}{% endraw %}` with `10.10.10.10`. {% assign dns_server = "{{ pillar['dns_server'] }}" %}
- `{{ dns_server }}` with `10.10.10.10`.
To do this automatically: To do this automatically:
@@ -40,7 +40,7 @@ The Kubernetes Charms use snap channels to drive payloads. The channels are defi
| beta | Latest alpha or beta of Kubernetes for that minor release | | beta | Latest alpha or beta of Kubernetes for that minor release |
| edge | Nightly builds of that minor release of Kubernetes | | edge | Nightly builds of that minor release of Kubernetes |
If a release isn't available, the next highest channel is used. For example, 1.6/beta will load `/candidate` or `/stable` depending on availablility of release. Development versions of Kubernetes are available in that minor releases edge channel. There is no guarantee that edge or master will work with the current charms. If a release isn't available, the next highest channel is used. For example, 1.6/beta will load `/candidate` or `/stable` depending on availability of release. Development versions of Kubernetes are available in that minor releases edge channel. There is no guarantee that edge or master will work with the current charms.
## Master Upgrades ## Master Upgrades
+1 -1
View File
@@ -55,7 +55,7 @@ The following labels and definitions should be used to prioritize issues. If you
## Handling special issue types ## Handling special issue types
### Duplicate issues ### Duplicate issues
If a single problem has one or more issues open for it, the problem should be consolodated into a single issue. You should decide which issue to keep open (or open a new issue), port over all relevant information, link related issues, and close all the other issues that describe the same problem. Only having a single issue to work on will help reduce confusion and avoid duplicating work on the same problem. If a single problem has one or more issues open for it, the problem should be consolidated into a single issue. You should decide which issue to keep open (or open a new issue), port over all relevant information, link related issues, and close all the other issues that describe the same problem. Only having a single issue to work on will help reduce confusion and avoid duplicating work on the same problem.
### Dead link issues ### Dead link issues
Depending on where the dead link is reported, different actions are required to resolve the issue. Dead links in the API and Kubectl docs are automation issues and should be assigned a P1 until the problem can be fully understood. All other dead links are issues that need to be manually fixed and can be assigned a P3. Depending on where the dead link is reported, different actions are required to resolve the issue. Dead links in the API and Kubectl docs are automation issues and should be assigned a P1 until the problem can be fully understood. All other dead links are issues that need to be manually fixed and can be assigned a P3.
+1 -1
View File
@@ -231,7 +231,7 @@ I didn't read the stlye guide.
### Ordered Lists ### Ordered Lists
Callouts will interupt numbered lists unless you indent three spaces before the notice and the tag. Callouts will interrupt numbered lists unless you indent three spaces before the notice and the tag.
For example: For example:
@@ -127,7 +127,7 @@ $ kubectl get crontab -o json
"uid": "6f65e7a3-8601-11e6-a23e-42010af0000c" "uid": "6f65e7a3-8601-11e6-a23e-42010af0000c"
} }
} }
] ],
"kind": "List", "kind": "List",
"metadata": {}, "metadata": {},
"resourceVersion": "", "resourceVersion": "",
@@ -148,7 +148,7 @@ program to retrieve the contents of your secret.
Since secrets are encrypted on write, performing an update on a secret will encrypt that content. Since secrets are encrypted on write, performing an update on a secret will encrypt that content.
``` ```
kubectl get secrets -o json | kubectl replace -f - kubectl get secrets --all-namespaces -o json | kubectl replace -f -
``` ```
The command above reads all secrets and then updates them to apply server side encryption. The command above reads all secrets and then updates them to apply server side encryption.
@@ -26,9 +26,89 @@ The Weave Net Addon for Kubernetes comes with a [Network Policy Controller](http
{% endcapture %} {% endcapture %}
{% capture example %}
## Namespace isolation example
1. Create a namespace with `DefaultDeny`.
```yaml
kind: Namespace
apiVersion: v1
metadata:
name: myns
annotations:
net.beta.kubernetes.io/network-policy: |
{
"ingress": {
"isolation": "DefaultDeny"
}
}
```
2. Create 2 pods inside this namespace.
```yaml
kind: Pod
apiVersion: v1
metadata:
name: pod1
namespace: myns
labels:
inns: "yes"
spec:
containers:
- name: pod1
image: nginx
---
kind: Pod
apiVersion: v1
metadata:
name: pod2
namespace: myns
labels:
inns: "yes"
spec:
containers:
- name: pod2
image: nginx
```
3. Get the IP addresses of the pods.
```shell
kubectl get po -n myns -o wide
```
**Note:** If your cURL requests to pods are forbidden, try making cURL requests to other pods from within a pod.
{: .note}
4. Create a Kubernetes NetworkPolicy that allows pods within the same namespace to connect with each other.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: aaa
namespace: myns
spec:
podSelector:
matchExpressions:
- {key: inns, operator: In, values: ["yes"]}
ingress:
- from:
- podSelector:
matchExpressions:
- {key: inns, operator: In, values: ["yes"]}
```
**Caution:** After applying the network policy, pods outside the namespace you specify may be unable to connect with pods inside the namespace.
{. :caution}
{% endcapture %}
{% capture whatsnext %} {% capture whatsnext %}
Once you have installed the Weave Net Addon you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy. Once you have installed the Weave Net addon, you can follow the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) to try out Kubernetes NetworkPolicy.
{% endcapture %} {% endcapture %}
@@ -223,7 +223,7 @@ metadata:
ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable.
The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap. The ConfigMap API resource stores configuration data as key-value pairs. The data can be consumed in pods or provide the configurations for system components such as controllers. ConfigMap is similar to [Secrets](/docs/concepts/configuration/secret/), but provides a means of working with strings that don't contain sensitive information. Users and system components alike can store configuration data in ConfigMap.
Note: ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the a Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume. Note: ConfigMaps should reference properties files, not replace them. Think of the ConfigMap as representing something similar to the Linux `/etc` directory and its contents. For example, if you create a [Kubernetes Volume](/docs/concepts/storage/volumes/) from a ConfigMap, each data item in the ConfigMap is represented by an individual file in the volume.
The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`. The ConfigMap's `data` field contains the configuration data. As shown in the example below, this can be simple -- like individual properties defined using `--from-literal` -- or complex -- like configuration files or JSON blobs defined using `--from-file`.
@@ -136,7 +136,7 @@ Any code greater than or equal to 200 and less than 400 indicates success. Any
other code indicates failure. other code indicates failure.
You can see the source code for the server in You can see the source code for the server in
[server.go](http://k8s.io/docs/user-guide/liveness/image/server.go). [server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/liveness/server.go).
For the first 10 seconds that the Container is alive, the `/healthz` handler For the first 10 seconds that the Container is alive, the `/healthz` handler
returns a status of 200. After that, the handler returns a status of 500. returns a status of 200. After that, the handler returns a status of 500.
@@ -234,7 +234,7 @@ special.level
special.type special.type
``` ```
### Add ConfigMap data to a specific path in the Volume: ### Add ConfigMap data to a specific path in the Volume
Use the `path` field to specify the desired file path for specific ConfigMap items. Use the `path` field to specify the desired file path for specific ConfigMap items.
In this case, the `special.level` item will be mounted in the `config-volume` volume at `/etc/config/keys`. In this case, the `special.level` item will be mounted in the `config-volume` volume at `/etc/config/keys`.
@@ -50,7 +50,7 @@ Here is a video showing how to setup and run a Google Cloud Monitoring backed He
[![how to setup and run a Google Cloud Monitoring backed Heapster](http://img.youtube.com/vi/xSMNR2fcoLs/0.jpg)](http://www.youtube.com/watch?v=xSMNR2fcoLs) [![how to setup and run a Google Cloud Monitoring backed Heapster](http://img.youtube.com/vi/xSMNR2fcoLs/0.jpg)](http://www.youtube.com/watch?v=xSMNR2fcoLs)
Here is a snapshot of the a Google Cloud Monitoring dashboard showing cluster-wide resource usage. Here is a snapshot of the Google Cloud Monitoring dashboard showing cluster-wide resource usage.
![Google Cloud Monitoring dashboard](/images/docs/gcm.png) ![Google Cloud Monitoring dashboard](/images/docs/gcm.png)
@@ -67,9 +67,9 @@ kubefed is available as a [snap](https://snapcraft.io/) application.
1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with: 1. If you are on Ubuntu or one of other Linux distributions that support [snap](https://snapcraft.io/docs/core/install) package manager, you can install with:
sudo snap install kubefed --classic sudo snap install kubefed --classic
2. Run `kubefed version` to verify that the verison you've installed is sufficiently up-to-date. 2. Run `kubefed version` to verify that the version you've installed is sufficiently up-to-date.
## Choosing a host cluster. ## Choosing a host cluster.
@@ -422,7 +422,7 @@ in the federation don't follow
In such cases, you can specify a cluster name that conforms to the In such cases, you can specify a cluster name that conforms to the
[RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules [RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) label naming rules
and specify the cluster context using the `--cluster-context` flag. and specify the cluster context using the `--cluster-context` flag.
For example, if context of the cluster your are joining is For example, if context of the cluster you are joining is
`gondor_needs-no_king`, then you can join the cluster by running: `gondor_needs-no_king`, then you can join the cluster by running:
```shell ```shell
@@ -60,8 +60,8 @@ We may check the current status of autoscaler by running:
```shell ```shell
$ kubectl get hpa $ kubectl get hpa
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 50% 0% 1 10 18s php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s
``` ```
@@ -85,8 +85,8 @@ Within a minute or so, we should see the higher CPU load by executing:
```shell ```shell
$ kubectl get hpa $ kubectl get hpa
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE NAME REFERENCE TARGET CURRENT MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 50% 305% 1 10 3m php-apache Deployment/php-apache/scale 305% / 50% 305% 1 10 1 3m
``` ```
@@ -114,8 +114,8 @@ Then we will verify the result state (after a minute or so):
```shell ```shell
$ kubectl get hpa $ kubectl get hpa
NAME REFERENCE TARGET CURRENT MINPODS MAXPODS AGE NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
php-apache Deployment/php-apache/scale 50% 0% 1 10 11m php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m
$ kubectl get deployment php-apache $ kubectl get deployment php-apache
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
+1 -1
View File
@@ -30,7 +30,7 @@ file "redis-deployment.yaml" created
## Installation ## Installation
We have multiple ways to install Kompose. Our prefered method is downloading the binary from the latest GitHub release. We have multiple ways to install Kompose. Our preferred method is downloading the binary from the latest GitHub release.
### GitHub release ### GitHub release
+3 -1
View File
@@ -9,7 +9,9 @@ each of which has a sequence of steps.
* [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features. * [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) is an in-depth interactive tutorial that helps you understand the Kubernetes system and try out some basic Kubernetes features.
* [Online Training Course](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) * [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
* [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/) * [Hello Minikube](/docs/tutorials/stateless-application/hello-minikube/)
@@ -484,7 +484,7 @@ TODO(1.6): For 1.6, add the following bullet point to 1.
### How different types of fields are merged ### How different types of fields are merged
How a particular field in a configuration file is merged with How a particular field in a configuration file is merged with
with the live configuration depends on the the live configuration depends on the
type of the field. There are several types of fields: type of the field. There are several types of fields:
- *primitive*: A field of type string, integer, or boolean. - *primitive*: A field of type string, integer, or boolean.