Ambassador pattern
The ambassador pattern is about representing a remote service as if it were local and possibly enforcing some policy. A good example of the ambassador pattern is if you have a Redis cluster with one master for writes and many replicas for reads. A local ambassador container can serve as a proxy and expose Redis to the main application container on the localhost. The main application container simply connects to Redis on localhost:6379 (Redis default port), but it connects to the ambassador running in the same pod, which filters the requests, and sends write requests to the real Redis master and read requests randomly to one of the read replicas. Just like with the sidecar pattern, the main application has no idea what's going on. That can help a lot when testing against a real local Redis. Also, if the Redis cluster configuration changes, only the ambassador needs to be modified; the main application remains blissfully unaware.
How to update Kubernetes Dashboard in hosted Kubernetes on GKE?
We are using the hosted version of Kubernetes inside Google Container Engine (GKE).
Currently we are at Version 1.3.x, which comes with an Kubernetes Dashboard v1.1.1.
Some days ago Kubernetes Dashboard v1.4.0 was released which includes some very nice enhancements.
My Question: What is the recommended way to update the Kubernetes Dashboard on a hosted (GKE) Kubernetes cluster?
The cluster comes with a Dashboard controlled by an Replication Controller. We could just dump the RC config, edit the image tag and labels and apply it. But I don't want to break the dashboard. So I'd like to know what the "official" or suggested way of doing this is.
BEST ANSWER:
The official way is to update your cluster to 1.4. It should be available a few days after Kubernetes 1.4 is released. You can do this via gcloud CLI or Google Cloud Console (click "Upgrade available" next to your cluster).
If you hear a voice within you say 'you cannot paint', then by all means paint and that voice will be silenced.
Vincent Van Gogh