Kubernetes Container Specification Definition

Kubernetes Container Specification Definition is the precise characterization of the container spec, the structured schema, defined within a Pod's spec.containers (or spec.initContainers) list, that fully describes a single container: the image it runs, the command and arguments it executes, the resources it consumes, the ports it exposes, the environment and volumes it has access to, and the probes used to assess its health. It is formally an element of a Pod's specification, never an object in its own right, since a container has no independent identity or lifecycle apart from the Pod that declares it.

Required and Core Fields

name and image

Every container specification requires a name, unique within its Pod, used to distinguish it in status reporting, logs, and exec commands, and an image, identifying the container image to run, typically as a registry path with a tag or digest.

containers:
  - name: api
    image: codartium/api:4.1.0

command and args

command overrides the image's default entrypoint, and args supplies arguments to whichever entrypoint ultimately runs, whether the image's default or the overridden command, together determining the exact process the container executes.

containers:
  - name: migrate
    image: codartium/migrator:2.0.0
    command: ["python"]
    args: ["migrate.py", "--verbose"]

Resource Fields

resources.requests and resources.limits

The resources field formally declares a container's CPU, memory, and any extended resource requirements as requests, the minimum guaranteed and the value used by the scheduler, and limits, the maximum enforced by the kubelet and container runtime at runtime.

containers:
  - name: api
    image: codartium/api:4.1.0
    resources:
      requests:
        cpu: "250m"
        memory: "256Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"

Networking Fields

ports

The ports field declares the network ports a container listens on; it is formally informational for most purposes, documenting intended usage, since a container's ports are already reachable within the Pod's shared network namespace regardless of whether they are declared, but is required for named ports referenced elsewhere.

containers:
  - name: api
    image: codartium/api:4.1.0
    ports:
      - name: http
        containerPort: 8080

Environment and Configuration Fields

env and envFrom

env declares individual environment variables, each either a literal value or sourced dynamically from a ConfigMap key, Secret key, or another field of the Pod itself; envFrom bulk-imports every key from a referenced ConfigMap or Secret as environment variables in one declaration.

containers:
  - name: api
    image: codartium/api:4.1.0
    env:
      - name: LOG_LEVEL
        value: "info"
      - name: DB_PASSWORD
        valueFrom:
          secretKeyRef:
            name: codartium-db-credentials
            key: password
    envFrom:
      - configMapRef:
          name: codartium-app-config

volumeMounts

volumeMounts declares which of the Pod's shared volumes this specific container mounts, and at what filesystem path, formally establishing the container's view into storage defined at the Pod level rather than within the container specification itself.

containers:
  - name: api
    image: codartium/api:4.1.0
    volumeMounts:
      - name: cache
        mountPath: /var/cache/api

Health and Security Fields

Probes

livenessProbe, readinessProbe, and startupProbe are each declared per container, formally independent of one another and of any other container in the same Pod, allowing each container to define its own criteria for liveness, readiness, and startup completion.

containers:
  - name: api
    image: codartium/api:4.1.0
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080

securityContext

A container-level securityContext formally overrides or supplements the Pod-level securityContext for that specific container, controlling attributes such as the user ID it runs as, whether privilege escalation is permitted, and which Linux capabilities it holds.

containers:
  - name: api
    image: codartium/api:4.1.0
    securityContext:
      runAsNonRoot: true
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

What the Container Specification Does Not Include

No Independent Scheduling or Identity

A container specification carries no node placement fields, no independent name uniqueness across the cluster, and no lifecycle status of its own separate from status.containerStatuses on its parent Pod; every one of these properties belongs formally to the Pod, not to the individual container specification nested within it.

kubectl get pod codartium-api-abc123 -o jsonpath='{.spec.containers[*].name}'
kubectl exec -it codartium-api-abc123 -c api -- sh