cs_integrations.md

copyright	lastupdated
years 2014, 2018	2018-04-11

{:new_window: target="_blank"} {:shortdesc: .shortdesc} {:screen: .screen} {:pre: .pre} {:table: .aria-labeledby="caption"} {:codeblock: .codeblock} {:tip: .tip} {:download: .download}

Integrating services

{: #integrations}

You can use various external services and catalog services with a standard Kubernetes cluster in {{site.data.keyword.containerlong}}. {:shortdesc}

Application services

Table. Integration options for application services

Service	Description
{{site.data.keyword.blockchainfull}}	Deploy a publicly available development environment for IBM Blockchain to a Kubernetes cluster in {{site.data.keyword.containerlong_notm}}. Use this environment to develop and customize your own blockchain network to deploy apps that share an immutable ledger for recording the history of transactions. For more information, see Develop in a cloud sandbox IBM Blockchain Platform .

DevOps services

Table. Integration options for managing DevOps

Service	Description
Codeship	You can use Codeship for the continuous integration and delivery of containers. For more information, see Using Codeship Pro To Deploy Workloads to {{site.data.keyword.containershort_notm}} .
Helm	Helm is a Kubernetes package manager. You can create new Helm charts or use preexisting Helm charts to define, install, and upgrade complex Kubernetes applications that run in {{site.data.keyword.containerlong_notm}} clusters. For more information, see [Setting up Helm in {{site.data.keyword.containershort_notm}}](cs_integrations.html#helm).
{{site.data.keyword.contdelivery_full}}	Automate your app builds and container deployments to Kubernetes clusters by using a toolchain. For setup information, see the blog Deploy Kubernetes pods to the {{site.data.keyword.containerlong_notm}} using DevOps Pipelines .
Istio	Istio is an open source service that gives developers a way to connect, secure, manage, and monitor a network of microservices, also known a service mesh, on cloud orchestration platforms like Kubernetes. Check out the blog post about how IBM co-founded and launched Istio to find out more about the open-source project. To install Istio on your Kubernetes cluster in {{site.data.keyword.containershort_notm}} and get started with a sample app, see [Tutorial: Managing microservices with Istio](cs_tutorials_istio.html#istio_tutorial).

Logging and monitoring services

Table. Integration options for managing logs and metrics

Service	Description
CoScale	Monitor worker nodes, containers, replica sets, replication controllers, and services with CoScale . For more information, see Monitoring {{site.data.keyword.containershort_notm}} with CoScale .
Datadog	Monitor your cluster and view infrastructure and application performance metrics with Datadog . For more information, see Monitoring {{site.data.keyword.containershort_notm}} with Datadog .
{{site.data.keyword.loganalysisfull}}	Expand your log collection, retention, and search abilities with {{site.data.keyword.loganalysisfull_notm}}. For more information, see Enabling automatic collection of cluster logs .
{{site.data.keyword.monitoringlong}}	Expand your metrics collection and retention capabilities by defining rules and alerts with {{site.data.keyword.monitoringlong_notm}}. For more information, see Analyze metrics in Grafana for an app that is deployed in a Kubernetes cluster .
Instana	Instana provides infrastructure and app performance monitoring with a GUI that automatically discovers and maps your apps. Istana captures every request to your apps, which lets you troubleshoot and perform root cause analysis to prevent the problems from happening again. Check out the blog post about deploying Istana in {{site.data.keyword.containershort_notm}} to learn more.
Prometheus	Prometheus is an open source monitoring, logging, and alerting tool that was specifically designed for Kubernetes to retrieve detailed information about the cluster, worker nodes, and deployment health based on the Kubernetes logging information. The CPU, memory, I/O, and network activity of all running containers in a cluster are collected and can be used in custom queries or alerts to monitor performance and workloads in your cluster. To use Prometheus, follow the the CoreOS instructions .
Sematext	View metrics and logs for your containerized applications by using Sematext . For more information, see Monitoring & logging for containers with Sematext .
Sysdig	Capture app, container, statsd, and host metrics with a single instrumentation point by using Sysdig . For more information, see Monitoring {{site.data.keyword.containershort_notm}} with Sysdig Container Intelligence .
Weave Scope	Weave Scope provides a visual diagram of your resources within a Kubernetes cluster, including services, pods, containers, processes, nodes, and more. Weave Scope provides interactive metrics for CPU and memory and also provides tools to tail and exec into a container. For more information, see [Visualizing Kubernetes cluster resources with Weave Scope and {{site.data.keyword.containershort_notm}}](cs_integrations.html#weavescope).

Security services

Table. Integration options for managing security

Service	Description
{{site.data.keyword.appid_full}}	Add a level of security to your apps with [{{site.data.keyword.appid_short}}](/docs/services/appid/index.html#gettingstarted) by requiring users to sign in. To authenticate web or API HTTP/HTTPS requests to your app, you can integrate {{site.data.keyword.appid_short_notm}} with your Ingress service by using the [{{site.data.keyword.appid_short_notm}} authentication Ingress annotation](cs_annotations.html#appid-auth).
Aqua Security	As a supplement to Vulnerability Advisor, you can use Aqua Security to improve the security of container deployments by reducing what your app is allowed to do. For more information, see Protecting container deployments on {{site.data.keyword.Bluemix_notm}} with Aqua Security .
{{site.data.keyword.cloudcerts_full}}	You can use {{site.data.keyword.cloudcerts_long}} to store and manage SSL certificates for your apps. For more information, see Use {{site.data.keyword.cloudcerts_long_notm}} with {{site.data.keyword.containershort_notm}} to deploy custom domain TLS Certificates .
{{site.data.keyword.registrylong}}	Set up your own secured Docker image repository where you can safely store and share images between cluster users. For more information, see the {{site.data.keyword.registrylong}} documentation .
NeuVector	Protect containers with a cloud-native firewall by using NeuVector . For more information, see NeuVector Container Security .
Twistlock	As a supplement to Vulnerability Advisor, you can use Twistlock to manage firewalls, threat protection, and incident response. For more information, see Twistlock on {{site.data.keyword.containershort_notm}} .

Storage services

Table. Integration options for persistent storage

Service	Description
{{site.data.keyword.cos_full}}	Data that is stored with {{site.data.keyword.cos_short}} is encrypted and dispersed across multiple geographic locations, and accessed over HTTP by using a REST API. You can use the [ibm-backup-restore image](/docs/services/RegistryImages/ibm-backup-restore/index.html) to configure the service to make one-time or scheduled backups for data in your clusters. For general information about the service, see the {{site.data.keyword.cos_short}} documentation .
{{site.data.keyword.cloudantfull}}	{{site.data.keyword.cloudant_short_notm}} is a document-oriented DataBase as a Service (DBaaS) that stores data as documents in JSON format. The service is built for scalability, high availability, and durability. For more information, see the {{site.data.keyword.cloudant_short_notm}} documentation .
{{site.data.keyword.composeForMongoDB_full}}	{{site.data.keyword.composeForMongoDB}} delivers high availability and redundancy, automated and on-demand no-stop backups, monitoring tools, integration into alert systems, performance analysis views, and more. For more information, see the {{site.data.keyword.composeForMongoDB}} documentation .

Adding Cloud Foundry services to clusters

{: #adding_cluster}

Add an existing Cloud Foundry service instance to your cluster to enable your cluster users to access and use the service when they deploy an app to the cluster. {:shortdesc}

Before you begin:

1. Target your CLI to your cluster.
2. Request an instance of the {{site.data.keyword.Bluemix_notm}} service. Note: To create an instance of a service in the Washington DC location, you must use the CLI.
3. Cloud Foundry services are supported to bind with clusters, but other services are not. You can see the different service types after you create the service instance and the services are grouped in the dashboard as Cloud Foundry Services and Services. To bind the services in the Services section with clusters, first create Cloud Foundry aliases.

Note:

• You can only add {{site.data.keyword.Bluemix_notm}} services that support service keys. If the service does not support service keys, see [Enabling external apps to use {{site.data.keyword.Bluemix_notm}} services](/docs/apps/reqnsi.html#accser_external).
• The cluster and the worker nodes must be deployed fully before you can add a service.

To add a service: 2. List available {{site.data.keyword.Bluemix_notm}} services.

```
bx service list
```
{: pre}

Example CLI output:

```
name                      service           plan    bound apps   last operation
<service_instance_name>   <service_name>    spark                create succeeded
```
{: screen}

3. Note the name of the service instance that you want to add to your cluster.

4. Identify the cluster namespace that you want to use to add your service. Choose between the following options.

   • List existing namespaces and choose a namespace that you want to use.

     kubectl get namespaces
     

     {: pre}

   • Create a new namespace in your cluster.

     kubectl create namespace <namespace_name>
     

     {: pre}

5. Add the service to your cluster.

   bx cs cluster-service-bind <cluster_name_or_id> <namespace> <service_instance_name>
   

   {: pre}

   When the service is successfully added to your cluster, a cluster secret is created that holds the credentials of your service instance. Example CLI output:

   bx cs cluster-service-bind mycluster mynamespace cleardb
   Binding service instance to namespace...
   OK
   Namespace:	mynamespace
   Secret name:     binding-<service_instance_name>
   

   {: screen}

6. Verify that the secret was created in your cluster namespace.

   kubectl get secrets --namespace=<namespace>
   

   {: pre}

To use the service in a pod that is deployed in the cluster, cluster users can access the service credentials of the {{site.data.keyword.Bluemix_notm}} service by mounting the Kubernetes secret as a secret volume to a pod.

Creating Cloud Foundry aliases for other {{site.data.keyword.Bluemix_notm}} service resources

{: #adding_resource_cluster}

Cloud Foundry services are supported for binding with clusters. To bind an {{site.data.keyword.Bluemix_notm}} service that is not a Cloud Foundry service to your cluster, create a Cloud Foundry alias for the service instance. {:shortdesc}

Before you begin, request an instance of the {{site.data.keyword.Bluemix_notm}} service.

To create a Cloud Foundry alias for the service instance:

1. Target the org and a space where the service instance is created.

   bx target -o <org_name> -s <space_name>
   

   {: pre}

2. Note the service instance name.

   bx resource service-instances
   

   {: pre}

3. Create a Cloud Foundry alias for the service instance.

   bx resource service-alias-create <service_alias_name> --instance-name <service_instance>
   

   {: pre}

4. Verify that the service alias was created.

   bx service list
   

   {: pre}

5. Bind the Cloud Foundry alias to the cluster.

Adding services to apps

{: #adding_app}

Encrypted Kubernetes secrets are used to store {{site.data.keyword.Bluemix_notm}} service details and credentials and allow secure communication between the service and the cluster. {:shortdesc}

Kubernetes secrets are a secure way to store confidential information, such as user names, passwords, or keys. Rather than exposing confidential information via environment variables or directly in the Dockerfile, cluster users can mount secrets to a pod. Then, those secrets can be accessed by a running container in a pod.

When you mount a secret volume to your pod, a file named binding is stored in the volume mount directory that includes all information and credentials that you need to access the {{site.data.keyword.Bluemix_notm}} service.

Before you begin, target your CLI to your cluster. Make sure that the {{site.data.keyword.Bluemix_notm}} service that you want to use in your app was added to the cluster by the cluster admin.

1. List available secrets in your cluster namespace.

   kubectl get secrets --namespace=<my_namespace>
   

   {: pre}

   Example output:

   NAME                                    TYPE                                  DATA      AGE
   binding-<service_instance_name>         Opaque                                1         3m
   
   

   {: screen}

2. Look for a secret of type Opaque and note the name of the secret. If multiple secrets exist, contact your cluster administrator to identify the correct service secret.

3. Open your preferred editor.

4. Create a YAML file to configure a pod that can access the service details through a secret volume. If you bound more than one service, verify that each secret is associated with the correct service.

   apiVersion: apps/v1beta1
   kind: Deployment
   metadata:
     labels:
       app: secret-test
     name: secret-test
     namespace: <my_namespace>
   spec:
     selector:
       matchLabels:
         app: secret-test
     replicas: 1
     template:
       metadata:
         labels:
           app: secret-test
       spec:
         containers:
         - image: nginx
           name: secret-test
           volumeMounts:
           - mountPath: /opt/service-bind
             name: service-bind-volume
         volumes:
         - name: service-bind-volume
           secret:
             defaultMode: 420
             secretName: binding-<service_instance_name>
   

   {: codeblock}

   Understanding the YAML file components
   volumeMounts/mountPath	The name of the secret volume that you want to mount to your container.
   volumes/name	Enter a name for the secret volume that you want to mount to your container.
   secret/defaultMode	Set read-only permissions for the service secret.
   secret/secretName	Enter the name of the secret that you noted earlier.

5. Create the pod and mount the secret volume.

   kubectl apply -f <yaml_path>
   

   {: pre}

6. Verify that the pod is created.

   kubectl get pods --namespace=<my_namespace>
   

   {: pre}

   Example CLI output:

   NAME                           READY     STATUS    RESTARTS   AGE
   secret-test-1111454598-gfx32   1/1       Running   0          1m
   

   {: screen}

7. Note the NAME of your pod.

8. Get the details about the pod and look for the secret name.

   kubectl describe pod <pod_name>
   

   {: pre}

   Output:

   ...
   Volumes:
     service-bind-volume:
       Type:       Secret (a volume populated by a Secret)
       SecretName: binding-<service_instance_name>
   ...
   

   {: screen}

9. When implementing your app, configure it to find the secret file named binding in the mount directory, parse the JSON content and determine the URL and service credentials to access your {{site.data.keyword.Bluemix_notm}} service.

You can now access the {{site.data.keyword.Bluemix_notm}} service details and credentials. To work with your {{site.data.keyword.Bluemix_notm}} service, make sure your app is configured to find the service secret file in the mount directory, parse the JSON content and determine the service details.

Setting up Helm in {{site.data.keyword.containershort_notm}}

{: #helm}

Helm is a Kubernetes package manager. You can create Helm charts or use preexisting Helm charts to define, install, and upgrade complex Kubernetes applications that run in {{site.data.keyword.containerlong_notm}} clusters. {:shortdesc}

Before using Helm charts with {{site.data.keyword.containershort_notm}}, you must install and initialize a Helm instance your cluster. You can then add the {{site.data.keyword.Bluemix_notm}} Helm repository to your Helm instance.

Before you begin, target your CLI to the cluster where you want to use a Helm chart.

1. Install the Helm CLI .

2. Important: To maintain cluster security, create a service account for Tiller in the kube-system namespace and a Kubernetes RBAC cluster role binding for the tiller-deploy pod.

   1. In your preferred editor, create the following file and save it as rbac-config.yaml. Note:
      • The cluster-admin cluster role is created by default in Kubernetes clusters, so you don’t need define it explicitly.
      • If you are using a version 1.7.x cluster, change the apiVersion to rbac.authorization.k8s.io/v1beta1.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: tiller
     namespace: kube-system
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: tiller
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: cluster-admin
   subjects:
     - kind: ServiceAccount
       name: tiller
       namespace: kube-system
   

   {: codeblock}

   2. Create the service account and cluster role binding.

      kubectl create -f rbac-config.yaml
      

      {: pre}

3. Initialize Helm and install tiller with the service account that you created.

   helm init --service-account tiller
   

   {: pre}

4. Verify that the tiller-deploy pod has a Status of Running in your cluster.

   kubectl get pods -n kube-system -l app=helm
   

   {: pre}

   Example output:

   NAME                            READY     STATUS    RESTARTS   AGE
   tiller-deploy-352283156-nzbcm   1/1       Running   0          2m
   

   {: screen}

5. Add the {{site.data.keyword.Bluemix_notm}} Helm repository to your Helm instance.

   helm repo add ibm  https://registry.bluemix.net/helm/ibm
   

   {: pre}

6. List the Helm charts currently available in the {{site.data.keyword.Bluemix_notm}} repository.

   helm search ibm
   

   {: pre}

7. To learn more about a chart, list its settings and default values.

   For example, to view the settings, documentation, and default values for the strongSwan IPSec VPN service Helm chart:

   helm inspect ibm/strongswan
   

   {: pre}

Related Helm links

{: #helm_links}

• To use the strongSwan Helm chart, see Setting up VPN connectivity with the strongSwan IPSec VPN service Helm chart.
• View available Helm charts that you can use with {{site.data.keyword.Bluemix_notm}} in the Helm Charts Catalog GUI.
• Learn more about the Helm commands that are used to set up and manage Helm charts in the Helm documentation .
• Learn more about how you can increase deployment velocity with Kubernetes Helm Charts .

Visualizing Kubernetes cluster resources

{: #weavescope}

Weave Scope provides a visual diagram of your resources within a Kubernetes cluster, including services, pods, containers, and more. Weave Scope provides interactive metrics for CPU and memory and tools to tail and exec into a container. {:shortdesc}

Before you begin:

• Remember not to expose your cluster information on the public internet. Complete these steps to deploy Weave Scope securely and access it from a web browser locally.
• If you do not have one already, create a standard cluster. Weave Scope can be CPU intensive, especially the app. Run Weave Scope with larger standard clusters, not free clusters.
• Target your CLI to your cluster to run kubectl commands.

To use Weave Scope with a cluster: 2. Deploy one of the provided RBAC permissions configuration file in the cluster.

To enable read/write permissions:

```
kubectl apply -f "https://raw.githubusercontent.com/IBM-Cloud/kube-samples/master/weave-scope/weave-scope-rbac.yaml"
```
{: pre}

To enable read-only permissions:

```
kubectl apply --namespace weave -f "https://raw.githubusercontent.com/IBM-Cloud/kube-samples/master/weave-scope/weave-scope-rbac-readonly.yaml"
```
{: pre}

Output:

```
clusterrole "weave-scope-mgr" created
clusterrolebinding "weave-scope-mgr-role-binding" created
```
{: screen}

3. Deploy the Weave Scope service, which is privately accessible by the cluster IP address.

   kubectl apply --namespace weave -f "https://cloud.weave.works/k8s/scope.yaml?k8s-version=$(kubectl version | base64 | tr -d '\n')"
   

   Output:

   serviceaccount "weave-scope" created
   deployment "weave-scope-app" created
   service "weave-scope-app" created
   daemonset "weave-scope-agent" created
   

   {: screen}

4. Run a port forwarding command to bring up the service on your computer. Now that Weave Scope is configured with the cluster, to access Weave Scope next time, you can run this port forwarding command without completing the previous configuration steps again.

   kubectl port-forward -n weave "$(kubectl get -n weave pod --selector=weave-scope-component=app -o jsonpath='{.items..metadata.name}')" 4040
   

   {: pre}

   Output:

   Forwarding from 127.0.0.1:4040 -> 4040
   Forwarding from [::1]:4040 -> 4040
   Handling connection for 4040
   

   {: screen}

5. Open your web browser to http://localhost:4040. Without the default components deployed, you see the following diagram. You can choose to view topology diagrams or tables of the Kubernetes resources in the cluster.

   

Learn more about the Weave Scope features .