Merge branch 'master' into patch-1

This commit is contained in:
Ivan Font
2017-11-27 18:03:46 -08:00
committed by GitHub
73 changed files with 2238 additions and 708 deletions
@@ -136,7 +136,7 @@ import (
// creates the clientset
clientset, _:= kubernetes.NewForConfig(config)
// access the API to list pods
pods, _:= clientset.Core().Pods("").List(v1.ListOptions{})
pods, _:= clientset.CoreV1().Pods("").List(v1.ListOptions{})
fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
...
```
@@ -17,7 +17,7 @@ can develop their features independantly from the core Kubernetes release cycles
Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go#L29-L50) is satisifed.
To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvier](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52) where a global variable of available cloud providers is updated.
To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52) where a global variable of available cloud providers is updated.
## Developing
@@ -67,7 +67,7 @@ status:
services.nodeports: "0"
```
## Create a PersistentVolumeClaim:
## Create a PersistentVolumeClaim
Here is the configuration file for a PersistentVolumeClaim object:
@@ -92,7 +92,7 @@ NAME STATUS
pvc-quota-demo Pending
```
## Attempt to create a second PersistentVolumeClaim:
## Attempt to create a second PersistentVolumeClaim
Here is the configuration file for a second PersistentVolumeClaim:
@@ -36,7 +36,9 @@ The data source corresponds to a key-value pair in the ConfigMap, where
* key = the file name or the key you provided on the command line, and
* value = the file contents or the literal value you provided on the command line.
You can use [`kubectl describe`](/docs/user-guide/kubectl/{{page.version}}/#describe) or [`kubectl get`](/docs/user-guide/kubectl/{{page.version}}/#get) to retrieve information about a ConfigMap. The former shows a summary of the ConfigMap, while the latter returns the full contents of the ConfigMap.
You can use [`kubectl describe`](/docs/user-guide/kubectl/{{page.version}}/#describe) or
[`kubectl get`](/docs/user-guide/kubectl/{{page.version}}/#get) to retrieve information
about a ConfigMap.
### Create ConfigMaps from directories
@@ -16,33 +16,12 @@ your pods. But there are a number of ways to get even more information about you
For this example we'll use a Deployment to create two pods, similar to the earlier example.
```yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "128Mi"
cpu: "500m"
ports:
- containerPort: 80
```
{% include code.html language="yaml" file="nginx-dep.yaml" ghlink="/docs/tasks/debug-application-cluster/nginx-dep.yaml" %}
Copy this to a file *./my-nginx-dep.yaml*
Create deployment by running following command:
```shell
$ kubectl create -f ./my-nginx-dep.yaml
$ kubectl create -f https://k8s.io/docs/tasks/debug-application-cluster/nginx-dep.yaml
deployment "nginx-deployment" created
```
@@ -0,0 +1,20 @@
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "128Mi"
cpu: "500m"
ports:
- containerPort: 80
@@ -371,44 +371,35 @@ For more information see
## Adding a cluster to a federation
Once you've deployed a federation control plane, you'll need to make
that control plane aware of the clusters it should manage. You can add
a cluster to your federation by using the [`kubefed join`](/docs/admin/kubefed_join/)
command. A new context will have been added to your kubeconfig named `fellowship`
(after the name of your federation). To join clusters into the federation, you will
need to change the context.
After you've deployed a federation control plane, you'll need to make that control plane aware of the clusters it should manage.
```
kubectl config use-context fellowship
```
To join clusters into the federation:
To use `kubefed join`, you'll need to provide the name of the cluster
you want to add to the federation, and the `--host-cluster-context`
for the federation control plane's host cluster.
1. Change the context:
> Note: The name that you provide to the `join` command is used as the
joining cluster's identity in federation. This name should adhere to
the rules described in the
[identifiers doc](/docs/concepts/overview/working-with-objects/names/). If the context
corresponding to your joining cluster conforms to these rules then you
can use the same name in the join command. Otherwise, you will have to
choose a different name for your cluster's identity. For more
information, please see the
[naming rules and customization](#naming-rules-and-customization)
section below.
kubectl config use-context fellowship
The following example command adds the cluster `gondor` to the
federation running on host cluster `rivendell`:
1. If you are using a managed cluster service, allow the service to access the cluster. To do this, create a `clusterrolebinding` for the account associated with your cluster service:
```
kubefed join gondor --host-cluster-context=rivendell
```
kubectl create clusterrolebinding <your_user>-cluster-admin-binding --clusterrole=cluster-admin --user=<your_user>@example.org --context=<joining_cluster_context
1. Join the cluster to the federation, using `kubefed join`, and make sure you provide the following:
* The name of the cluster that you are joining to the federation
* `--host-cluster-context`, the kubeconfig context for the host cluster
For example, this command adds the cluster `gondor` to the federation running on host cluster `rivendell`:
```
kubefed join gondor --host-cluster-context=rivendell
```
A new context has now been added to your kubeconfig named `fellowship` (after the name of your federation).
> Note: The name that you provide to the `join` command is used as the joining cluster's identity in federation. If this name adheres to the rules described in the [identifiers doc](/docs/concepts/overview/working-with-objects/names/). If the context
corresponding to your joining cluster conforms to these rules then you can use the same name in the join command. Otherwise, you will have to choose a different name for your cluster's identity.
> Note: Kubernetes requires that you manually join clusters to a
federation because the federation control plane manages only those
clusters that it is responsible for managing. Adding a cluster tells
the federation control plane that it is responsible for managing that
cluster.
### Naming rules and customization
@@ -37,7 +37,7 @@ username and password:
1. Create the Secret
kubectl create -f secret.yaml
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret.yaml
**Note:** If you want to skip the Base64 encoding step, you can create a Secret
by using the `kubectl create secret` command:
@@ -81,7 +81,7 @@ Here is a configuration file you can use to create a Pod:
1. Create the Pod:
kubectl create -f secret-pod.yaml
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret-pod.yaml
1. Verify that your Pod is running:
@@ -128,7 +128,7 @@ Here is a configuration file you can use to create a Pod:
1. Create the Pod:
kubectl create -f secret-envars-pod.yaml
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/secret-envars-pod.yaml
1. Verify that your Pod is running:
@@ -10,7 +10,7 @@ metadata:
spec:
containers:
- name: website
image: ecorp/website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
namespace: myns
spec:
selector:
matchLabels:
@@ -8,7 +8,7 @@ metadata:
spec:
containers:
- name: website
image: ecorp/website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
namespace: myns
spec:
selector:
matchLabels:
@@ -10,7 +10,7 @@ metadata:
spec:
containers:
- name: website
image: ecorp/website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
@@ -11,7 +11,7 @@ metadata:
spec:
containers:
- name: website
image: ecorp/website
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
@@ -8,7 +8,7 @@ metadata:
spec:
containers:
- name: website
image: ecorp/website
image: nginx
ports:
- containerPort: 80
@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: allow-database
namespace: myns
spec:
selector:
matchLabels:
@@ -2,7 +2,6 @@ apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: proxy
namespace: myns
spec:
selector:
matchLabels:
@@ -20,18 +20,50 @@ You can get an overview of PodPresets at
This is a simple example to show how a Pod spec is modified by the Pod
Preset.
**User submitted pod spec:**
{% include code.html language="yaml" file="podpreset-preset.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-preset.yaml" %}
Create the PodPreset:
```shell
kubectl create -f https://k8s.io/docs/tasks/inject-data-application/podpreset-preset.yaml
```
Examine the created PodPreset:
```shell
$ kubectl get podpreset
NAME AGE
allow-database 1m
```
The new PodPreset will act upon any pod that has label `role: frontend`.
{% include code.html language="yaml" file="podpreset-pod.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-pod.yaml" %}
**Example Pod Preset:**
Create a pod:
{% include code.html language="yaml" file="podpreset-preset.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-preset.yaml" %}
```shell
$ kubectl create -f https://k8s.io/docs/tasks/inject-data-application/podpreset-pod.yaml
```
List the running Pods:
```shell
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
website 1/1 Running 0 4m
```
**Pod spec after admission controller:**
{% include code.html language="yaml" file="podpreset-merged.yaml" ghlink="/docs/tasks/inject-data-application/podpreset-merged.yaml" %}
To see above output, run the following command:
```shell
$ kubectl get pod website -o yaml
```
### Pod Spec with `ConfigMap` Example
This is an example to show how a Pod spec is modified by the Pod Preset
@@ -113,7 +145,7 @@ when there is a conflict.
**If we run `kubectl describe...` we can see the event:**
```
```shell
$ kubectl describe ...
....
Events:
@@ -0,0 +1,100 @@
---
title: Install Service Catalog using Helm
approvers:
- chenopis
---
{% capture overview %}
{% glossary_definition term_id="service-catalog" length="long" %}
Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster. Up to date information on this process can be found at the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/docs/install.md) repo.
{% endcapture %}
{% capture prerequisites %}
* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
* Service Catalog requires a Kubernetes cluster running version 1.7 or higher.
* You must have a Kubernetes cluster with cluster DNS enabled.
* If you are using a cloud-based Kubernetes cluster or {% glossary_tooltip text="Minikube" term_id="minikube" %}, you may already have cluster DNS enabled.
* If you are using `hack/local-up-cluster.sh`, ensure that the `KUBE_ENABLE_CLUSTER_DNS` environment variable is set, then run the install script.
* [Install and setup kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) v1.7 or higher. Make sure it is configured to connect to the Kubernetes cluster.
* Install [Helm](http://helm.sh/) v2.7.0 or newer.
* Follow the [Helm install instructions](https://github.com/kubernetes/helm/blob/master/docs/install.md).
* If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm.
{% endcapture %}
{% capture steps %}
## Add the service-catalog Helm repository
Once Helm is installed, add the *service-catalog* Helm repository to your local machine by executing the following command:
```shell
helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
```
Check to make sure that it installed successfully by executing the following command:
```shell
helm search service-catalog
```
If the installation was successful, the command should output the following:
```
NAME VERSION DESCRIPTION
svc-cat/catalog 0.0.1 service-catalog API server and controller-manag...
```
## Enable RBAC
Your Kubernetes cluster must have RBAC enabled, which requires your Tiller Pod(s) to have `cluster-admin` access.
If you are using {% glossary_tooltip text="Minikube" term_id="minikube" %}, run the `minikube start` command with the following flag:
```shell
minikube start --extra-config=apiserver.Authorization.Mode=RBAC
```
If you are using `hack/local-up-cluster.sh`, set the `AUTHORIZATION_MODE` environment variable with the following values:
```
AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O
```
By default, `helm init` installs the Tiller Pod into the `kube-system` namespace, with Tiller configured to use the `default` service account.
**NOTE:** If you used the `--tiller-namespace` or `--service-account` flags when running `helm init`, the `--serviceaccount` flag in the following command needs to be adjusted to reference the appropriate namespace and ServiceAccount name.
{: .note}
Configure Tiller to have `cluster-admin` access:
```shell
kubectl create clusterrolebinding tiller-cluster-admin \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:default
```
## Install Service Catalog in your Kubernetes cluster
Install Service Catalog from the root of the Helm repository using the following command:
```shell
helm install svc-cat/catalog \
--name catalog --namespace catalog
```
{% endcapture %}
{% capture whatsnext %}
* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
{% endcapture %}
{% include templates/task.md %}
@@ -0,0 +1,77 @@
---
title: Install Service Catalog using SC
approvers:
- chenopis
---
{% capture overview %}
{% glossary_definition term_id="service-catalog" length="long" %}
Use the [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation) tool to easily install or uninstall Service Catalog on your Kubernetes cluster. This CLI tool is installed as `sc` in your local environment.
{% endcapture %}
{% capture prerequisites %}
* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
* Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`.
* Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts.
* Service Catalog requires Kubernetes version 1.7+.
* [Install and setup kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) so that it is configured to connect to a Kubernetes v1.7+ cluster.
* The kubectl user must be bound to the *cluster-admin* role for it to install Service Catalog. To ensure that this is true, run the following command:
kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
{% endcapture %}
{% capture steps %}
## Install `sc` in your local environment
Install the `sc` CLI tool using the `go get` command:
```Go
go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc
```
After running the above command, `sc` should be installed in your `GOPATH/bin` directory.
## Install Service Catalog in your Kubernetes cluster
First, verify that all dependencies have been installed. Run:
```shell
sc check
```
If the check is successful, it should return:
```
Dependency check passed. You are good to go.
```
Next, run the install command and specify the `storageclass` that you want to use for the backup:
```shell
sc install --etcd-backup-storageclass "standard"
```
## Uninstall Service Catalog
If you would like to uninstall Service Catalog from your Kubernetes cluster using the `sc` tool, run:
```shell
sc uninstall
```
{% endcapture %}
{% capture whatsnext %}
* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
{% endcapture %}
{% include templates/task.md %}