Architecture

The high-level architecture of Rancher

The diagram shows a Rancher Server installation that manages two downstream Kubernetes clusters: one created by RKE and another made by Amazon EKS (Elastic Kubernetes Service). The main Rancher server is the main controller where you manage all downstream k8 clusters via UI/CLI/API. A Rancher agent is deployed to talk to the rancher server in each downstream cluster.

Installation

Installation on Kubernetes cluster (on EKS)

Add the Helm Chart Repository

helm repo add rancher-stable https://releases.rancher.com/server-charts/stable

Connect to Kubernetes cluster and create a namespace for the Rancher

kubectl create namespace cattle-system

SSL Configurations [Using Rancher Generated Certificates (Default)]. For other SSL configurations options visit this link.

# Install the CustomResourceDefinition resources separately
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.0.4/cert-manager.crds.yaml
kubectl create namespace cert-manager
helm repo add jetstack https://charts.jetstack.io
helm repo update
# Install the cert-manager Helm chart
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --version v1.0.4

Setup Ingress controller to access the Rancher. You can find more options to setup the ingress Nginx controller here.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.47.0/deploy/static/provider/aws/deploy.yaml

Install Rancher with Helm

helm install rancher rancher-stable/rancher \
  --namespace cattle-system \
  --set hostname=<hostname> \  # ex.- rancher-server.example.com
  --set replicas=3
# Verify that the rancher server is successfully deployed 
kubectl get pods -n cattle-system  
kubectl -n cattle-system get deploy rancher
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
rancher   3/3     3            3           47h

Update the route 53 DNS zones and map load balancer with the rancher hostname i.e rancher-server.example.com. Once done you can see the cluster is onboard in the Rancher.

Kubernetes Cluster

Import the existing Kubernetes clusters

Go to Rancher main page to add cluster and select cluster type

Provide any logical name for cluster to create and import cluster

Log in to the existing cluster that you want to import to the rancher. And apply the kubectl command that you copied from the "Add Cluster" step.

curl --insecure -sfL https://rancher-server.devops.godmode.in/v3/import/46bvqblb6p68szrk76vks5w2tbgdr5wrz25j8v4bnqgrsmxwl254h7_c-tthw7.yaml | kubectl apply -f -    

Once done you can see the cluster is on-bored in the rancher

Dashboards

Imported Cluster main dashboard

Workload View

Feature

Continuous Deployment

Continuous Deployment provides a feature to deploy your applications on the Kubernetes cluster. This feature allows you to configure the repository path where your manifest resides, watch the changes, and then automatically trigger the pipeline to deploy the application.

Select target cluster and goto cluster explorer

Select Continuous Delivery from the drop-down

Create a new pipeline and fill out all details

Name : Name of pipeline
Repository : configured the appropriate repo
Paths: The root of the repo is used by default. To use one or more different directories, add them here.
Deploy To: You can select all cluster, group of cluster and individual clusters as target

Git hub repo contains sample YAML.

# r-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: rancher-prod-app
  name: rancher-prod-app
  namespace: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: rancher-prod-app
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: rancher-prod-app
    spec:
      containers:
      - image: gcr.io/cloudcover-sandbox/demoapp:v2
        name: demoapp
        resources: {}

# r-svc.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: rancher-prod-app
  name: rancher-prod-app
  namespace: demo
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: rancher-prod-app
  type: LoadBalancer

Whenever you change the yaml's, this will trigger the pipeline and the application will get deployed on target clusters. For example; Currently our application is running on version v2 on the target cluster

Let's do some changes in the manifest. We are updating the image tag from v2 to v8. You can see the changes in the pipeline itself and in the workload section, our application is updating already.

Ci/Cd Pipeline

CICD Pipeline for multi-cloud providers

We are going to update the existing application to the newer version on a single Kubernetes cluster via pipeline features. Once the application is deployed on a single cluster, we will be deploying the same application on other clusters via Continues Delivery using the catalog template.

PFB the details of the stages mentioned above:

Step 1

Clone: Get the copy of the git repo

Step 2

Build and Publish: Build the docker image and publish it to the google docker registry(GCR)

Step 3

Deploy: Rollout the changes on a single Kubernetes cluster

Step 4

PublishCatalogConfig: Publish the template onto the target git repo, this will trigger the continuous delivery pipeline and update/create the resources on target clusters.

Add external registry to project to upload the docker images

Global → Cluster → Resources → Secrets → Registry Credential → Add Registry

Configure CatalogTemplateConfig

Refer to the git-repository to get the stage information.

- name: PublishCatlog
  steps:
  - publishCatalogConfig:
      path: deploy
      catalogTemplate: nginx-web
      version: latest
      gitUrl: git@github.com:nikhil-cldcvr/spinnkaer-canarry-web-app.git
      gitBranch: rancher
      gitAuthor: nikhil
      gitEmail: nikhil.pandit@cldcvr.com
    envFrom:
    - sourceName: git-key
      sourceKey: DEPLOY_KEY
      targetKey: DEPLOY_KEY
    when:
      event:
        include:
        - tag

Create a secret using private ssh-key

cp ~/.ssh/id_rsa /tmp/DEPLOY_KEY
kubectl create secret generic git-key --from-file=/tmp/DEPLOY_KEY -n p-tmmcv-pipeline

Continuous Delivery

Create cluster group using labels and selector

Create a git repo to watch the changes from the branch.

Workflow

The current version of the application is v2

Let's update the code to v3 and deploy it on the target cluster.

Once the changes are deployed on one cluster, the PublishCatalogConfig job will update the gitRepo which is configured in the continuous delivery pipeline, then rollout action is triggered to update the existing applications to a newer version.

Check the status of the application on target clusters.