This document contains instructions for installing the Service Catalog onto Kubernetes clusters running version 1.6. Since Service Catalog only officially supports versions 1.7 and later, these instructions are deprecated and may be removed at any time.
If you are running a Kubernetes cluster running version 1.7 or later, please see the installation instructions for 1.7.
You must have a Kubernetes cluster with cluster DNS enabled. We can't list instructions here for enabling cluster DNS for all Kubernetes cluster installations, but here are a few notes:
- If you are using Google Container Engine or minikube, you likely have cluster DNS enabled already.
- If you are using hack/local-up-cluster.sh, ensure the
KUBE_ENABLE_CLUSTER_DNS
environment variable is set as follows:
KUBE_ENABLE_CLUSTER_DNS=true hack/local-up-cluster.sh -O
You must use Helm v2.5.0 or newer in the installation steps below.
If you already have an appropriate Helm version, execute helm init
(if you haven't already) to install Tiller (the server-side component of Helm),
and you should be done with Helm setup.
If you don't already have an appropriate version, see the Helm installation instructions.
If your kubernetes cluster has
RBAC enabled, you must
ensure that the tiller pod has cluster-admin
access. By default, helm init
installs the tiller pod into kube-system
namespace, with tiller configured to
use the default
service account.
kubectl create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
cluster-admin
access is required in order for helm to work correctly in
clusters with RBAC enabled. If you used the --tiller-namespace
or
--service-account
flags when running helm init
, the --serviceaccount
flag
in the previous command needs to be adjusted to reference the appropriate
namespace and ServiceAccount name.
You need to download the charts/catalog directory to your local machine. Please refer to here for the guide.
As with Kubernetes itself, interaction with the service catalog system is
achieved through the kubectl
command line interface. Chances are high that
you already have this installed, however, the service catalog requires
kubectl
version 1.6 or newer.
To proceed, we must:
- Download and install
kubectl
version 1.6 or newer. - Configure
kubectl
to communicate with the service catalog's API server.
To install kubectl
follow the standard instructions.
For example, on a mac,
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
chmod +x ./kubectl
We'll assume hereafter that all kubectl
commands are using this
newly-installed executable.
The service catalog is packaged as a Helm chart located in the charts/catalog directory in this repository, and supports a wide variety of customizations which are detailed in that directory's README.md.
We'll be interacting with a variety of resources in the following steps. The service catalog API server needs to store all of these resources in a data store. The data store implementation in the API server is pluggable, but we currently support only Etcd 3.
The first implementation requires that the API server has access to an Etcd 3 cluster, and the second only requires access to the Kubernetes API to store TPRs.
Even if you store data in TPRs, you should still access data via the service catalog API. It is possible to access data via the TPRs directly, but we don't recommend it.
To install the service catalog system with Etcd 3 as the backing data store:
helm install charts/catalog --name catalog --namespace catalog
Regardless of which data store implementation you choose, the remainder of the steps in this walkthrough will stay the same.
Authentication and authorization are disabled in the Helm chart by default. To enable them,
set the apiserver.auth.enabled
option on the Helm chart:
helm install charts/catalog --name catalog --namespace catalog --set apiserver.auth.enabled=true
For more information about certificate setup, see the documentation on authentication and authorization.
If you make a mistake somewhere along the way in this walk-through and want to start over, please run the following commands for clean-up.
helm delete --purge catalog
kubectl delete ns catalog
To configure kubectl
to communicate with the service catalog API server, we'll have to
get the IP address that points to the Service
that sits in front of the API server pod(s).
If you installed the catalog with one of the helm install
commands above, then this service
will be called catalog-catalog-apiserver
, and be in the catalog
namespace.
How you get this IP address is highly dependent on your Kubernetes installation
method. Regardless of how you do it, do not use the Cluster IP of the
Service
. The Service
is created as a NodePort
in this walkthrough, you
will need to use the address of one of the nodes in your cluster.
When you determine the IP address of this service, set its value into the SVC_CAT_API_SERVER_IP
environment variable and then run the following commands:
kubectl config set-cluster service-catalog --server=https://${SVC_CAT_API_SERVER_IP}:30443 --insecure-skip-tls-verify=true
kubectl config set-context service-catalog --cluster=service-catalog
Note: Your cloud provider may require firewall rules to allow your traffic get in. Please refer to the Troubleshooting section of the walkthrough document for details.