Kubernetes CKAD weekly challenge #7 Migrate a ServiceKim WuestkampBlockedUnblockFollowFollowingMay 6For information and tips read this.
Rules!be fast, avoid creating yaml manually from scratchuse only kubernetes.
io/docs for help.
check my solution after you did yours.
You probably have a better one!Todays Task: Simulate migration phase of external serviceLet’s say we have a running cluster but one service is still outside.
We pretend www.
google.
de:80 is our external service which we would like to migrate into the cluster in a few phases.
Between each phase there could be days or weeks passing, but we simulate this in one go today.
Create a deployment called compute of three replicas of image byrnedo/alpine-curl which keep running for a while.
Make sure they can reach our external service: curl www.
google.
com:80We will move this service soon inside the cluster.
But till then we create an ExternalName service called webapi which points to www.
google.
com:80.
Make sure our pods can reach that internal service and get forwarded to our external one.
curl webapi –header “Host: www.
google.
com"Create a deployment called nginx of image nginx.
We pretend this is a replica of our external www.
google.
com:80Change the internal webapi service to no longer point to the external DNS but our internal nginx pod.
Test the connection from compute pods to webapi service: curl webapiSolution# 1 Cluster connected to external servicekubectl run –helpkubectl run compute –image=byrnedo/alpine-curl –replicas=3 –command — /bin/sh -c "sleep 10d"kubectl exec compute-66f769c5d9-6chc9 — curl www.
google.
de:80We now have a running cluster which can reach our external web service.
#2 Migration phase with ExternalName servicekubectl create service –helpkubectl create service externalname –helpkubectl create service externalname webapi –external-name www.
google.
comkubectl describe service webapikubectl exec compute-fd98796c6-27w65 — ping webapikubectl exec compute-fd98796c6-27w65 — curl webapi –header "Host: www.
google.
com" # we can reach home of www.
google.
comInstead of using the external DNS name we can now use our internal service name webapi.
This means we can redirect all internal requests already to this dns name although it’s still outside the cluster.
#3 Migrate the external service inside the clusterkubectl run nginx –image nginx # might be more complex in prod :DWe imagine the internal nginx deployment is a running replica of our external service www.
google.
com:80, both are now running simultaneously in this transitioning phase.
#4 Point webapi service to internal nginxNow it’s time to no longer send requests to www.
google.
com:80 but our internal nginx pod.
kubectl get service webapi -o yaml –export > webapi.
yamlNow edit webapi.
yaml to something like this (we change the service type from ExternalName to ClusterIP):apiVersion: v1kind: Servicemetadata: name: webapispec: selector: run: nginx ports: – name: "80" port: 80 targetPort: 80 type: ClusterIPMake sure the selector refers to the correct labels of your nginx pod.
Then apply the changes and check connectivity:kubectl delete -f webapi.
yamlkubectl create -f webapi.
yamlkubectl exec compute-fd98796c6-27w65 — ping webapikubectl exec compute-fd98796c6-27w65 — curl webapiThe curl webapi did still point to www.
google.
com, probably because of some DNS caching on the pod I thought.
So I tried recreating all pods (kubectl delete pod –all) but this didn’t change.
The webapi name was still resolved even if I removed the webapi service completely!.So it must be Kubernetes dns caching.
To flush dns resolution I identified the kube-dns pod and forced its recreation:kubectl get pod -n kube-system | grep dnskubectl delete pod kube-dns-86f4d74b45-z8lnskubectl exec compute-fd98796c6-27w65 — curl webapi # this now returns the default nginx page instead of www.
google.
com !Nice, we finished the migration.
As with all good migrations we had some little hickups but were able to solve this by “clearing” the kube dns cache (aka killing the kube-dns pod).
Let me know if there is a cleaner solution for this!Now we can shut down our outside service www.
google.
com:80 ;)EndThe ExternalName service is really useful when migrating an existing infrastructure into Kubernetes.
You can already create your whole service structure and use internal name resolution.
Then, step by step, you can change the services to point to inside objects just by changing the service type.
.