en:modul:m321_aws:topics:11

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

en:modul:m321_aws:topics:11 [2026/09/24 15:33] – angelegt dgaravaldien:modul:m321_aws:topics:11 [2026/09/24 15:38] (aktuell) – dgaravaldi
Zeile 10: Zeile 10:
 A Pod can have multiple containers running apps within it, but it can also have one or more init containers, which run before the app containers are started. A Pod can have multiple containers running apps within it, but it can also have one or more init containers, which run before the app containers are started.
  
-Init containers are exactly like regular containers, except:+Init containers are exactly like regular containers((see [[https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#differences-from-regular-containers|regular containers]])), except:
  
   * Init containers always run to completion.   * Init containers always run to completion.
Zeile 31: Zeile 31:
 ==== Differences from sidecar containers ==== ==== Differences from sidecar containers ====
  
-Init containers run and complete their tasks before the main application container starts. Unlike side containers, init containers are not continuously running alongside the main containers.+Init containers run and complete their tasks before the main application container starts. Unlike side containers((see [[https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/|sidecar containers]])), init containers are not continuously running alongside the main containers.
  
 Init containers run to completion sequentially, and the main container does not start until all the init containers have successfully completed. Init containers run to completion sequentially, and the main container does not start until all the init containers have successfully completed.
  
-init containers do not support ''lifecycle'', ''livenessProbe'', ''readinessProbe'', or ''startupProbe'' whereas sidecar containers support all these probes((see [[https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe|probes]])) to control their lifecycle.+init containers do not support ''lifecycle'', ''livenessProbe'', ''readinessProbe'', or ''startupProbe'' whereas sidecar containers support all these probes((see [[https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe|probes]])) to control their lifecycle((see [[https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle|Pod-lifecycle]])).
  
 Init containers share the same resources (CPU, memory, network) with the main application containers but do not interact directly with them. They can, however, use shared volumes for data exchange. Init containers share the same resources (CPU, memory, network) with the main application containers but do not interact directly with them. They can, however, use shared volumes for data exchange.
Zeile 45: Zeile 45:
   * Init containers can contain utilities or custom code for setup that are not present in an app image. For example, there is no need to make an image ''FROM'' another image just to use a tool like ''sed'', ''awk'', ''python'', or ''dig'' during setup.   * Init containers can contain utilities or custom code for setup that are not present in an app image. For example, there is no need to make an image ''FROM'' another image just to use a tool like ''sed'', ''awk'', ''python'', or ''dig'' during setup.
   * The application image builder and deployer roles can work independently without the need to jointly build a single app image.   * The application image builder and deployer roles can work independently without the need to jointly build a single app image.
-  * Init containers can run with a different view of the filesystem than app containers in the same Pod. Consequently, they can be given access to Secrets that app containers cannot access.+  * Init containers can run with a different view of the filesystem than app containers in the same Pod. Consequently, they can be given access to Secrets((see [[https://kubernetes.io/docs/concepts/configuration/secret/|Secrets]])) that app containers cannot access.
   * Because init containers run to completion before any app containers start, init containers offer a mechanism to block or delay app container startup until a set of preconditions are met. Once preconditions are met, all of the app containers in a Pod can start in parallel.   * Because init containers run to completion before any app containers start, init containers offer a mechanism to block or delay app container startup until a set of preconditions are met. Once preconditions are met, all of the app containers in a Pod can start in parallel.
   * Init containers can securely run utilities or custom code that would otherwise make an app container image less secure. By keeping unnecessary tools separate you can limit the attack surface of your app container image.   * Init containers can securely run utilities or custom code that would otherwise make an app container image less secure. By keeping unnecessary tools separate you can limit the attack surface of your app container image.
Zeile 131: Zeile 131:
 </code> </code>
  
- 
-==== More information ==== 
- 
-  * [[https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#differences-from-regular-containers|regular containers]] 
-  * [[https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/|sidecar containers]] 
-  * [[https://kubernetes.io/docs/concepts/configuration/secret/|Secrets]] 
-  * [[https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle|Pod-lifecycle]] 
  • en/modul/m321_aws/topics/11.1790256792.txt.gz
  • Zuletzt geändert: 2026/09/24 15:33
  • von dgaravaldi