@@ -35,12 +35,11 @@ Documentation for other releases can be found at
This example shows how to run OpenShift Origin as a pod on an existing Kubernetes cluster.
OpenShift Origin runs with a rich set of role based policy rules out of the box that requires authentication from users
via certificates. When run as a pod on an existing Kubernetes cluster, it proxies access to the underlying Kubernetes services
to provide security.
OpenShift Origin runs with a rich set of role based policy rules out of the box that requires authentication from users via certificates. When run as a pod on an existing Kubernetes cluster, it proxies access to the underlying Kubernetes services to provide security.
As a result, this example is a complex end-to-end configuration that shows how to configure certificates for a service that runs
on Kubernetes, and requires a number of configuration files to be injected dynamically via a secret volume to the pod.
As a result, this example is a complex end-to-end configuration that shows how to configure certificates for a service that runs on Kubernetes, and requires a number of configuration files to be injected dynamically via a secret volume to the pod.
This example will create a pod running the OpenShift Origin master. In addition, it will run a three-pod etcd setup to hold OpenShift content. OpenShift embeds Kubernetes in the stand-alone setup, so the configuration for OpenShift when it is running against an external Kubernetes cluster is different: content specific to Kubernetes will be stored in the Kubernetes etcd repository (i.e. pods, services, replication controllers, etc.), but OpenShift specific content (builds, images, users, policies, etc.) are stored in its etcd setup.
### Step 0: Prerequisites
...
...
@@ -59,10 +58,11 @@ $ vi cluster/saltbase/pillar/privilege.sls
allow_privileged: true
```
Now spin up a cluster using your preferred KUBERNETES_PROVIDER
Now spin up a cluster using your preferred KUBERNETES_PROVIDER. Remember that `kube-up.sh` may start other pods on your minion nodes, so ensure that you have enough resources to run the five pods for this example.
```sh
$ export KUBERNETES_PROVIDER=gce
$ export KUBERNETES_PROVIDER=${YOUR_PROVIDER}
$ cluster/kube-up.sh
```
...
...
@@ -72,6 +72,20 @@ Next, let's setup some variables, and create a local folder that will hold gener
This will have created a `etcd-controller.yaml.bak` file in your directory, which you should remember to restore when doing cleanup (or use the given `cleanup.sh`). Finally, let's start up the external etcd pods and the discovery service necessary for their initialization:
The output from this command will contain a single file that has all the required information needed to connect to your
Kubernetes cluster that you previously provisioned. This file should be considered sensitive, so do not share this file with
untrusted parties.
The output from this command will contain a single file that has all the required information needed to connect to your Kubernetes cluster that you previously provisioned. This file should be considered sensitive, so do not share this file with untrusted parties.
We will later use this file to tell OpenShift how to bootstap its own configuration.
### Step 2: Create an External Load Balancer to Route Traffic to OpenShift
An external load balancer is needed to route traffic to our OpenShift master service that will run as a pod on your
Kubernetes cluster.
An external load balancer is needed to route traffic to our OpenShift master service that will run as a pod on your Kubernetes cluster.
### Step 3: Generate configuration file for your OpenShift master pod
The OpenShift master requires a configuration file as input to know how to bootstrap the system.
In order to build this configuration file, we need to know the public IP address of our external load balancer in order to
build default certificates.
In order to build this configuration file, we need to know the public IP address of our external load balancer in order to build default certificates.
Grab the public IP address of the service we previously created: the two-line script below will attempt to do so, but make sure to check that the IP was set as a result - if it was not, try again after a couple seconds.
Grab the public IP address of the service we previously created.
```sh
$ export PUBLIC_IP=$(cluster/kubectl.sh get services openshift --template="{{ index .status.loadBalancer.ingress 0 \"ip\" }}")
$ echo$PUBLIC_IP
$ export PUBLIC_OPENSHIFT_IP=$(kubectl get services openshift --namespace="openshift-origin" --template="{{ index .status.loadBalancer.ingress 0 \"ip\" }}")
$ echo ${PUBLIC_OPENSHIFT_IP}
```
You can automate the process with the following script, as it might take more than a minute for the IP to be set and discoverable.
```shell
$ while[${#PUBLIC_OPENSHIFT_IP}-lt 1 ];do
echo-n.
sleep 1
{
export PUBLIC_OPENSHIFT_IP=$(kubectl get services openshift --namespace="openshift-origin"--template="{{ index .status.loadBalancer.ingress 0 \"ip\" }}")
$ echo"Public OpenShift IP set to: ${PUBLIC_OPENSHIFT_IP}"
```
Ensure you have a valid PUBLIC_IP address before continuing in the example.
We now need to run a command on your host to generate a proper OpenShift configuration. To do this, we will volume mount the configuration directory that holds your Kubernetes kubeconfig file from the prior step.
```sh
docker run --privileged-v${OPENSHIFT_CONFIG}:/config openshift/origin start master --write-config=/config --kubeconfig='/config/kubeconfig'--master='https://localhost:8443'--public-master='https://${PUBLIC_IP}:8443'
You should now see a number of certificates minted in your configuration directory, as well as a master-config.yaml file that tells the OpenShift master how to execute. In the next step, we will bundle this into a Kubernetes Secret that our OpenShift master pod will consume.
You should now see a number of certificates minted in your configuration directory, as well as a master-config.yaml file that tells the OpenShift master how to execute. We need to make some adjustments to this configuration directory in order to allow the OpenShift cluster to use Kubernetes serviceaccounts. First, write the Kubernetes service account key to the `${OPENSHIFT_CONFIG}` directory. The following script assumes you are using GCE. If you are not, use `scp` or `ssh` to get the key from the master node running Kubernetes. It is usually located at `/srv/kubernetes/server.key`.
Although we are retrieving the private key from the Kubernetes master, OpenShift will take care of the conversion for us so that serviceaccounts are created with the public key. Edit your `master-config.yaml` file in the `${OPENSHIFT_CONFIG}` directory to add `serviceaccounts.private.key` to the list of `publicKeyFiles`:
Now, the configuration files are complete. In the next step, we will bundle the resulting configuration into a Kubernetes Secret that our OpenShift master pod will consume.
### Step 4: Bundle the configuration into a Secret
**NOTE: This secret is secret and should not be shared with untrusted parties.**
...
...
@@ -156,7 +199,7 @@ We will deploy a pod that runs the OpenShift master. The OpenShift master will
system to manage Kubernetes specific resources. For the sake of simplicity, the OpenShift master will run with an embedded etcd to hold OpenShift specific content. This demonstration will evolve in the future to show how to run etcd in a pod so that content is not destroyed if the OpenShift master fails.
