Skip to main content
Version: Deploy 22.3

Kubernetes plugin

This topic covers the Deploy Kubernetes (K8s) plugin, which supports creating and managing Kubernetes resources such as Namespaces, Pods, Deployments, ConfigMaps, Secrets, and more, using various authentication methods.

The Deploy Kubernetes (K8s) plugin supports:

  • Creating Namespaces
  • Deploying Kubernetes Namespaces and Pods
  • Deploying Deployment Configs
  • Adding an assumed role to fetch the resources from the cluster
  • Adding service account based authentication
  • Mounting volumes on Kubernetes Pods
  • Deploying containers in the form of Pods, Deployments, and StatefulSets including all the configuration settings such as environment variables, networking, and volume settings, as well as liveness and readiness probes
  • Deploying volume configuration through PersistentVolumes, PersistentVolumeClaims, and StorageClasses
  • Deploying proxy objects such as Services and Ingresses
  • Deploying configuration objects such as ConfigMaps and Secrets

For more information about the Deploy Kubernetes plugin requirements and the configuration items (CIs) that the plugin supports, see the Kubernetes Plugin Reference.

Using the Deploy Kubernetes plugin

The Deploy Kubernetes plugin can create and destroy Kubernetes resources on a Kubernetes host. To use the plugin:

  1. Download the Deploy Kubernetes plugin ZIP from the distribution site.
  2. Unpack the plugin inside the XL_DEPLOY_SERVER_HOME/plugins/ directory.
  3. Restart Deploy.

With this plugin, Kubernetes host types and tasks specific for creating and removing Kubernetes resources are available to use in Deploy.

Set up the k8s.Master with minikube

  1. Hover over Infrastructure, click Menu button, click New, and select k8s.Master.

  2. Set up the k8s.Master authentication using one of these methods:

    • Client certificate authentication. Specify the following required properties:

      • apiServerURL: The URL for RESTful interface provided by the API Server
      • skipTLS: Do not verify using TLS/SSL
      • caCert: Certification authority certificate for server (example: .../.minikube/ca.crt)
      • tlsCert: TLS certificate for master server (example: .../.minikube/apiserver.crt)
      • tlsPrivateKey: TLS private key for master server (example: .../.minikube/apiserver.key)

      image

    • Username/password authentication

      • username: Username used for authentication
      • password: Password used for authentication

      image

    • Token authentication

      • token: Token used for authentication

      image

    • AWS EKS authentication. For an AWS EKS cluster, specify the following required properties:

      • isEKS: Check if the K8s cluster is an AWS EKS
      • clusterName: The AWS EKS cluster name
      • accessKey: The AWS Access Key
      • accessSecret: The AWS Access Secret

      image

Setting up the k8s.Master with GKE

  1. Hover over Infrastructure, click Menu button, click New, and select k8s.Master.
  2. Set up the k8s.Master authentication using one of these methods:
    • Client Certificate Authentication
    • Username/password Authentication
    • Token Authentication
  3. Follow the instructions described in Set up the k8s.Master with minikube. Collect the authentication information from the Google Cluster and create the k8s.Master.

Using Service Account Based Authentication functionality with GKE

  1. Hover over Infrastructure, click Menu button, click New, and select k8s.Master.

  2. In the Create k8s.Master page, select the is Google GKE check box and fill details of the Google Project ID, Google client Email, and Google Private Key fields. Collect the authentication information from google cluster and create k8s.Master as described in Setting up the k8s.Master with GKE section.

    image

Setting up the k8s.Master with AWS EKS

  1. Hover over Infrastructure, click Menu button, click New, and select k8s.Master. AWS EKS
  2. Expand the AWS EKS section, select the Is AWS EKS check box to inform Deploy that it is an EKS cluster.
  3. Select the Use Global STS check box if you want to use the global STS endpoint for token generation. However, if you want to use a regional STS endpoint (for example, sts.ap-southeast-2.amazonaws.com) for token generation, then clear the check box and provide the region name in the AWS STS region name field.

Note: You must also ensure that the region you provide as the AWS STS region name should have the STS token enabled.

  1. Provide the values for fields, such as EKS cluster name, AWS Access Key and AWS Access Secret.
  2. Under the Common section:
    • apiServerURL: The API server endpoint. Can be found in the Amazon Container Services EKS Control Panel
    • skipTLS: Do not verify using TLS/SSL
    • caCert: Certificate authority. Can be found in the Amazon Container Services EKS Control Panel (the CA certificate is base64 encoded by default in EKS Control Panel. Make sure is decrypted before copying to Deploy).
  3. Click Save or Save and close to save or save and proceed testing your configuration.

Using Assume Role functionality with EKS

  1. Hover over Infrastructure, click Menu button, click New, and select k8s.Master.

  2. Fill in the required information as mentioned in Setting up the k8s.Master with AWS EKS section.

  3. Select the is Assume Role"** check box and fill details of the Account Id, Role Name, Role Arn, Duration Seconds and Session Token fields. Collect the authentication information from AWS cloud IAM dashboard and create k8s.Master as described above.

    image

Verify the Kubernetes cluster connectivity

To verify the connection with the k8s.Master, use the Check Connection control task. If the task succeeds, the connectivity is working.

image

Create a new k8s.Namespace before any resource can be deployed to it

  • The k8s.Namespace is the container for all Kubernetes resources. You must deploy the Namespace through Deploy. The target Namespace must be deployed in different package than the one containing other Kubernetes resources such as Pod and Deployment.
  • The k8s.Namespace CI only requires the Namespace name. If the Namespace name is not specified, Deploy uses the CI name as namespace name.
  • The k8s.Namespace CI does not allow namespace name modification.

Use an existing or default namespace provided by the Kubernetes cluster

The Kubernetes cluster provides pre-created namespaces such as the default namespace. To use these existing namespaces in Deploy:

  1. Under Infrastructure, create the k8s.Namespace CI in k8s.Master.
  2. Provide the default Namespace name when default Namespace is required so that there is no need to have a provisioning package containing a Namespace.

image

Configure Kubernetes resources using YAML-based deployables

  • With the Kubernetes cluster, you can configure Kubernetes resources in Deploy.
  • You can configure YAML-based Kubernetes resources using the k8s.ResourcesFile CI. This CI requires the YAML file containing the definition of the Kubernetes resources that will be configured on the Kubernetes cluster.
  • The deployment order of Kubernetes resources through multiple YAML based CI is:
    • Separate YAML files for Kubernetes resources.
    • Deployment order and YAML files should match the resources dependency.
  • The k8s.ResourcesFile CI supports multiple API versions in the resource file. The plugin parses the file and creates a client based on the API version for each Kubernetes resource.
  • The YAML-based Kubernetes resources support multi-document YAML file for multiple Kubernetes resources in one file. Each resource within the YAML file is separated with dashes (---) and has its own API version. The deployment step order of the Kubernetes resources within the YAML based CI can be generated in two ways:
    1. The plugin parses the YAML file and automatically generates the deployment step order for each resource within the file, based on the type of the resource.
    2. For the resources of the same type within the file, the step order is generated on the basis of occurrence in the file. The step for the resource that occurs first is generated first and so on.

Example of a multi-document YAML with multiple API versions:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: hello-openshift
spec:
replicas: 7
template:
metadata:
labels:
app: hello
tier: backend
track: stable
spec:
containers:
- name: hello
image: "gcr.io/google-samples/hello-go-gke:1.0"
ports:
- name: http
containerPort: 80

---

apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm

Use CI-based deployables to configure Kubernetes resources

Deploy also provides CIs for Kubernetes resource deployment (example: k8s.Pod and k8s.Deployment). Deploy handles the asynchronous create/delete operation of resources. The CI based deployables support the latest API version, based on the latest Kubernetes version.