Auto-Reload from ConfigMap

My previous article “Inotify in Containers” has demonstrated that when ConfigMap is mounted as directories, any changes in the ConfigMap will propagate to related pods, and can be detected with inotify-like APIs. A follow-up question might be: what should a well-behaved application react to this trigger accordingly? What if it’s a ill-designed application? To clarify this I’ve conducted a series of experiments for 3 possible configmap-reloading strategies: Built-in auto-reloading apps External signals Pod rollout In this article I’m going to explain the experiments and preliminary findings.

Containers and Environment Variables

My previous article “Inotify in Containers” has demonstrated that when ConfigMap is mounted as directories, any changes in the ConfigMap will propagate to related pods. A follow-up question might be: what if the ConfigMap is mounted as environment variables? Some said that the answer is NO in Kubernetes1; even in the old Docker world2. Therefore, I’d like to begin with a simple experiment to try to answer the question: After

Inotify in Containers

It is usually necessary to watch for any changes in file systems, both in development and in production modes. For example, in the development mode Webpack can watch files and recompile whenever they change; in the production mode Consul Template can watch runtime configs and invoke specific applications whenever they change. These are well-known scenarios in traditional pre-container world. How about the container world? Do they behave the same in

Next '19 的 Istio 場次重點摘要

四月 9–11 日去舊金山參加 Google Cloud 的 Next ’19 大會,收穫頗大。

這場大會,同一時段就有近 30 場專題演講同時進行,議程滿滿,勢必得做取捨。基於工作需要及個人興趣,我主要選擇與容器相關的場次:service mesh、Windows containers、混合雲、資安實務。

我發現,光是這些場次,就得花很大力氣去消化、實驗與應用。

我們這些所謂的「台港團」會在 GCPUG Taipei 舉辦一場分享會。因為自己不克參加,便以這篇文章,針對我鎖定的核心議題:Istio,做一番重點摘要,以饗讀者。