side by side continuously (as in Example 15-1, where the Git synchronizer container continuously updates the local folder). We could also use a  Sidecar  and  Init Container together if both a guaranteed initialization and a constant update of the data are required. As you have seen, an init container is a Pod-level construct that gets activated after a Pod has been started. A few other related techniques used to initialize Kubernetes resources are different from init containers and worth listing here for completeness: There are many techniques for initializing Kubernetes resources. However, these techniques differ from admission webhooks because they validate and mutate resour‐ ces at creation time. You could use these techniques, for example, to inject an init Solution  |  129 More Initialization Techniques These are a set of plugins that intercept every request to the Kubernetes API Server before persistence of the object and can mutate or validate it. There are many controllers for applying checks, enforcing limits, and setting default values, but they are all compiled into the  kube-apiserver  binary, and configured by a cluster administrator when the API Server starts up. This plugin system is not very flexible, which is why admission webhooks were added to Kubernetes. These components are external admission controllers that perform HTTP call‐ backs for any matching request. There are two types of admission webhooks: the mutating webhook  (which can change resources to enforce custom defaults) and the  validating webhook  (which can reject resources to enforce custom admission policies). This concept of external controllers allows admission webhooks to be developed out of Kubernetes and configured at runtime. Initializers are useful for admins to force policies or to inject defaults by specify‐ ing a list of pending preinitialization tasks, stored in every object’s metadata. Then custom initializer controllers whose names correspond to the names of the tasks perform the tasks. Only after all initialization tasks are completed fully does the API object become visible to regular controllers. PodPresets are evaluated by another admission controller, which helps inject fields specified in a matching PodPreset into Pods at creation time. The fields can include volumes, volume mounts, or environment variables. Thus, PodPresets inject additional runtime requirements into a Pod at creation time using label selectors to specify the Pods to which a given PodPreset applies. PodPresets allow Pod template authors to automate adding repetitive information required for multiple Pods. Admission controllers Admission webhooks Initializers PodPresets