Last update:
Working with Kubernetes can be hard at the beginning. It is a complex orchestrator and you will probably spend a lot of time dealing with or finding a solution for a particular problem. I do the same, and I decided to write a series of posts which will cover different Kubernetes features. I will try to post at least two tips in each post. You will be able to find all tips using the tag kube-tips.
Expose External Service
Migrating production workloads to Kubernetes cluster is not easy. You can not just stop all services and start them on the Kubernetes cluster. Sometimes it is good to try to migrate services that are light and won't break your service. In the process, a probably good solution is to use your existing stateful services like DBs and just start with stateless containers first.
The easiest and right way to access external services from your pods is to create ExternalName service. It is a service without a selector. For example, if you decide to keep AWS RDS, but you also want to be able to use MySQL container for the testing environment. Let's take a look at this example:
kind: Service
apiVersion: v1
metadata:
name: test-service
namespace: default
spec:
type: ExternalName
externalName: test.database.example.com
You configured your web app to access a DB using URL test-service, but on your prod cluster DB is on AWS RDS and it has the following URL test.database.example.com. After you created ExternalName service and your web pod tries to access a DB on test-service, Kubernetes DNS server will return a CNAME record with the value test.database.example.com. Problem solved.
External service can also be used to access the service from a different namespace. For example:
kind: Service
apiVersion: v1
metadata:
name: test-service-1
namespace: namespace-a
spec:
type: ExternalName
externalName: test-service-2.namespace-b.svc.cluster.local
ports:
- port: 80
Here I can access the service test-service-2 from namespace-b, using the test-service-1 defined in namespace namespace-a.
Update Container Latest Image
When you try to create and test your Docker images on Kubernetes you will spend a lot of time rebuilding it. It is not good to use the latest tag for images in production (rolling upgrades will not work), but if you want to test something you need some easy way to pull the latest image without deleting and creating the Kubernetes Deployment. Simple solution - you could simply scale it to 0, and then to 1, or any number of replicas:
⚡ kubectl scale --replicas=0 deploy/my-app && kubectl scale --replicas=1 deploy/my-app
This will recreate the pod and pull the latest image.
NOTE: Make sure that imagePullPolicy is set to Always.
Stay tuned for the next one.