reference implementations


Applications (pods) are deployed into a namespace. These pods (docker images) are automatically provided with an private ip address via an internal DHCP server that uses the kube-dns resolver. The DNS server is configured to append the namespace to the search domain.

If an application was deployed into the staging namespace and needed to talk to the rabbitmq service in the staging namespace then configure the application to use the unqualified name as it will automatically expand.

nslookup rabbitmq

Name:   rabbitmq.staging.svc.cluster.local

If the application needs to talk to the rabbitmq service in the production namespace then use the fully qualified hostname ie. rabbitmq.production.svc.cluster.local

See https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ for more information.

external DNS

There's an addon called ExternalDNS that makes Kubernetes resources discoverable via public DNS servers and allows you to control DNS records dynamically via Kubernetes resources in a DNS provider-agnostic way.

event log

The event log for pods/containers can be accessed via

$ kutectl get events --watch

An interactive session can be launched to watch/follow the state of pods in the cluster via

$ kubectl get pods --watch

troubleshooting guides

The rule of thumb is when you do kubectl logs or kubectl exec the API server makes a request to the kubelet. If you experience problems then refer to this cheat cheat.

prefabricated applications

The equivilant of BitNami in the Kubernetes world is https://github.com/kubernetes/charts which are deployed using https://helm.sh/

recommended consumption