Curious to see CN-WAN Operator in action but feeling lazy about learning how it does stuff? Follow this guide!
To run this, make sure you have:
- Access to a Kubernetes cluster running at least version
1.11.3
with support for LoadBalancer type of services and that can perform outbound HTTP/S requests successfully. - Kubectl 1.11.3+
- A Project in Google Cloud with Service Directory enabled
- A Google Cloud Service Account with at least role
roles/servicedirectory.editor
.
Finally, kubeconfig needs to be properly set up.
git clone https://github.com/CloudNativeSDWAN/cnwan-operator.git
cd ./cnwan-operator
We will suppose you are deploying an application on your cluster where your employees can log in and watch training videos.
Run this to deploy a new namespace and a service in that namespace:
cat <<EOF | kubectl create -f -
kind: Namespace
apiVersion: v1
metadata:
name: training-app-namespace
labels:
purpose: "test"
operator.cnwan.io/watch: "enabled"
---
kind: Service
apiVersion: v1
metadata:
name: web-training
namespace: training-app-namespace
labels:
app: "training"
annotations:
version: "2.1"
traffic-profile: "standard"
spec:
ports:
- name: port80
protocol: TCP
port: 80
targetPort: 8080
selector:
app: "training"
type: LoadBalancer
EOF
Please notice that the namespace has this label: operator.cnwan.io/watch: enabled
which instructs the operator to watch events occurring in this namespace. Also notice that the service has annotations that will be registered as metadata:
annotations:
traffic-profile: standard
Now verify that the namespace is there:
kubectl get ns
NAME STATUS AGE
training-app-namespace Active 1h
Verify that the service is there and has an IP:
kubectl get service -n training-app-namespace
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web-training LoadBalancer 10.11.12.13 20.21.22.23 80:32058/TCP 1h
If you see <none>
or <pending>
under EXTERNAL-IP
you either have to wait to see an IP there or your cluster doesn't support LoadBalancer.
It doesn't really matter that there is no pod backing this service for now, as this is just a test. Of course, in a real world scenario you should make sure a pod is there.
Navigate to the root directory and place your service account to artifacts/secrets
, with name gcloud-credentials.json
.
From the root directory navigate to artifacts/settings
and modify the file settings.yaml
to look like this - please provide appropriate values in place of <gcloud-project>
and <gcloud-region>
:
serviceRegistry:
gcpServiceDirectory:
defaultRegion: <gcloud-region>
projectID: <gcloud-project-id>
watchNamespacesByDefault: false
serviceAnnotations:
- traffic-profile
- version
Please notice the values inside annotations
:
annotations:
- traffic-profile
- version
This means that the operator will register traffic-profile
as metadata if it finds it among a service's annotations list.
If you plan to run the operator in GKE, you can just write:
serviceRegistry:
gcpServiceDirectory: {}
watchNamespacesByDefault: false
serviceAnnotations:
- traffic-profile
- version
Explanation of this is explained here, but you can jump on that when you finish this quickstart.
From the root directory of the project, execute
./scripts/deploy.sh servicedirectory
Now, log in to Service Directory from the google cloud console and you will see a namespace that has the same name as the Kubernetes namespace where that service was found in.
If you click on it, you will see a service: its metadata contain traffic-profile: standard
. It will also contain an endpoint with data about the port and the address.
Now you're basically done, but you can follow these additional steps to see more of the operator in action.
Suppose you made a mistake: this is a training application where your employees will follow video tutorials. Therefore, its kind of traffic - or, profile, must be video
.
Execute:
kubectl annotate service web-training traffic-profile=video --overwrite -n training-app-namespace
The operator has updated the metadata in Service Directory accordingly.
Suppose you have a CI/CD pipeline that for each PR builds a container with a new tag. Also, it updates the service that serves the pods running that container by specifying the new version. Today, you will be that pipeline:
kubectl annotate service web-training version=2.2 -n training-app-namespace --overwrite
Once again, log in to Service Directory and see how the metadata for that service have changed accordingly.
Well, that's it for a quickstart. Now we encourage you to learn more about CN-WAN Operator by taking a look at the docs.
Also, make sure you read the official documentation of CN-WAN to learn how you can apply this simple quickstart to a real world scenario.
From the root directory of the project, run
./scripts/remove.sh
kubectl delete ns training-app-namespace