A primary container is the pod container that runs the main application process. Kubernetes starts it only after every init container has completed successfully. Other containers in the same pod can support it as sidecars. section 5.1.2 section 5.7
Use a primary container when:
- The pod has one main application process and complementary processes that must run beside it. section 5.1.2
- Initialization must finish before the application starts, such as a setup task or dependency connectivity check. section 5.5.2
- The application and its supporting containers share the pod’s lifecycle and should not be scaled independently. section 5.1.2
Kiada application with an Envoy sidecar
A pod can run the Kiada application as its primary container and Envoy as a sidecar. Init containers first perform a five-second initialization and a network connectivity check; after both finish, Kubernetes starts the Kiada and Envoy containers. Envoy converts HTTPS traffic to HTTP without changing the application. section 5.5.2 section 5.1.2
Listing 5.4 Defining init containers in a pod manifest
apiVersion: v1
kind: Pod
metadata:
name: kiada-init
spec:
initContainers: #1
- name: init-demo #2
image: luksa/init-demo:0.1 #2
- name: network-check #3
image: luksa/network-connectivity-checker:0.1 #3
containers: #4
- name: kiada #4
image: luksa/kiada:0.2 #4
stdin: true #4
ports: #4
- name: http #4
containerPort: 8080 #4
- name: envoy #4
image: luksa/kiada-ssl-proxy:0.1 #4
ports: #4
- name: https #4
containerPort: 8443 #4
- name: admin #4
containerPort: 9901 #4
Inspect the pod manifest to see initContainers declared separately from the regular containers that include the primary application and its sidecar. section 5.5.2
After initialization, regular containers are created in parallel in principle, although image-pull delays and post-start hooks can make their actual start times differ. A primary container can restart according to the pod’s restart policy. section 6.4.2
