Merge branch 'master' into patch-1
This commit is contained in:
@@ -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 %}
|
||||
Reference in New Issue
Block a user