Skip to content

Latest commit

 

History

History

2023-02-22-wgtn-cncf-meetup

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 

Connecting clouds the easy way, introducing Skupper

Exciting open source project Skupper opens up new opportunities for hybrid cloud and application migration, solving all manner of tricky multi-cluster and traditional infrastructure integration challenges.

In this session we will explore Skupper together, with live demos focused on overcoming the business challenges many of us encounter along our cloud native journeys.

./images/skupper-overview.png

You can watch a recording of this demo on youtube: https://www.youtube.com/watch?v=et-Oilr0Hz0

./images/video.png

Demo one - progressive migration

For our first demo we will highlight the possibility of progressive migrations, using the virtual application network of skupper to join two kubernetes clusters together so that we can have some application components migrated to a new cluster while the remaining application components continue to run in the old cluster.

Install skupper cli

The skupper command-line tool is the primary entrypoint for installing and configuring the Skupper infrastructure. You need to install the skupper cli only once for each development environment.

We can use the provided install script to install skupper:

curl https://skupper.io/install.sh | sh && skupper version

Deploy demo workload on premises

Before we get into deploying skupper lets get familiar with our demo workload which is a traditional three tier container based application for a medical clinic patient portal consisting of postgres database, java backend service and web frontend.

clear && export KUBECONFIG=$HOME/.kube/config

kubectl create namespace demo-onprem --dry-run=client --output yaml | kubectl apply --filename -
kubectl config set-context --current --namespace demo-onprem

kubectl create --filename 1-progressive-migration/database.yaml
kubectl rollout status deployment/database

kubectl create --filename 1-progressive-migration/backend.yaml
kubectl rollout status deployment/payment-processor

kubectl create --filename 1-progressive-migration/frontend.yaml
kubectl rollout status deployment/frontend

kubectl get pods
firefox --new-window "http://localhost:9090"

kubectl port-forward deployment/frontend 9090:8080 &

Initialise skupper on premises

Once we have skupper client installed and a workload running lets initialise skupper in the kubernetes cluster running on our local machine, this will be our “private” / “on premise” cluster for the purposes of the demo.

clear && skupper init --ingress nodeport --ingress-host localhost --enable-console --enable-flow-collector --console-auth unsecured && skupper status

kubectl get pods

With skupper initialised lets take a look at the included web console:

export port=$(kubectl get svc skupper --output jsonpath={.spec.ports[0].nodePort})

firefox --new-window "https://localhost:${port}"

Initialise skupper in public cluster

So we’ve been tasked with migrating this application to public cloud, rather than doing a big bang migration lets use skupper to perform a progressive migration. Our first step is to setup skupper in our public cloud cluster which is a managed ROSA cluster running in AWS.

clear && kubectl --kubeconfig=$HOME/.kube/rosa create namespace demo-public --dry-run=client --output yaml | kubectl --kubeconfig=$HOME/.kube/rosa apply --filename -

skupper --kubeconfig=$HOME/.kube/rosa --namespace demo-public init

kubectl --kubeconfig=$HOME/.kube/rosa --namespace demo-public get pods

Lets quickly review our public cluster deployment using the OpenShift console. Reviewing the demo-public project metrics we can see how lightweight a skupper installation is.

firefox --new-window "https://$(oc --kubeconfig ~/.kube/rosa get route --namespace openshift-console console --output jsonpath={.spec.host})/k8s/cluster/projects/demo-public"

Link public and private clusters

Creating a link requires use of two skupper commands in conjunction, skupper token create and skupper link create.

The skupper token create command generates a secret token that signifies permission to create a link. The token also carries the link details. Then, in a remote namespace, The skupper link create command uses the token to create a link to the namespace that generated it.

First, use skupper token create in one namespace to generate the token. Then, use skupper link create in the other to create a link.

clear && skupper --kubeconfig=$HOME/.kube/rosa --namespace demo-public token create 1-progressive-migration/secret.token

skupper link create --name "van" 1-progressive-migration/secret.token

Now that we have linked our clusters lets review the skupper interface to confirm that new link is present.

firefox --private-window "https://localhost:${port}"

Expose backend service to public cluster

With a virtual application network in place lets use it to expose our backend service to our public cluster.

clear && kubectl get svc --kubeconfig $HOME/.kube/rosa --namespace demo-public

skupper expose deployment/payment-processor --port 8080
skupper expose deployment/database --port 5432

kubectl get svc --kubeconfig $HOME/.kube/rosa --namespace demo-public

kubectl describe svc --kubeconfig $HOME/.kube/rosa --namespace demo-public payment-processor

Migrate frontend to public cluster

Our backend service is now available in our public cluster thanks to our skupper virtual application network so lets proceed with our cloud migration for our frontend.

We will scale up a fresh deployment on our public cluster, scale down on our on premises cluster then verify that our application frontend can still talk to our backend services and works as expected.

clear
kubectl --kubeconfig $HOME/.kube/rosa --namespace demo-public create --filename 1-progressive-migration/frontend.yaml
kubectl --kubeconfig $HOME/.kube/rosa --namespace demo-public rollout status deployment/frontend

oc --kubeconfig $HOME/.kube/rosa --namespace demo-public create route edge frontend --service=frontend
export route=$(oc --kubeconfig $HOME/.kube/rosa --namespace demo-public get routes frontend --output jsonpath="{.status.ingress[0].host}")

kubectl delete --filename 1-progressive-migration/frontend.yaml --ignore-not-found=true
firefox --new-window \
        --new-tab --url "https://localhost:${port}" \
        --new-tab --url "https://${route}"

In theory our application continues to run as normal, We just performed a progressive migration! 🎉

Teardown demo

Finished with the demo? Because skupper is so lightweight and only present in our application namespaces it will automatically be torn down when the namespaces are deleted, otherwise you can run the skupper delete to remove an installation from a namespace.

kubectl --kubeconfig $HOME/.kube/config delete namespace demo-onprem
kubectl --kubeconfig $HOME/.kube/rosa delete namespace demo-public