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
Kubernetes 的入門認知與導入策略
前天我在 2019 台灣雲端大會帶了兩個場次,一個是現場實作場次,一個是經驗分享演講:
-
Lab / 給 RD 的 Kubernetes 初體驗 (90 minutes)
-
Speech / 當 .NET 遇到 Kubernetes (30 minutes)
兩個場次,一言以蔽之,都圍繞在 Kubernetes 的入門認知與導入策略上。