API / Kaniko Interview Questions

🔰 Basic Level

1. What is Kaniko?

   • Kaniko is a tool to build container images from a Dockerfile, inside a container or Kubernetes pod, without requiring a Docker daemon.

2. Why is Kaniko used?

   • It's used in CI/CD pipelines and Kubernetes environments where running a Docker daemon is insecure or not possible (e.g., in a containerized environment).

3. Can you use Kaniko without root privileges?

   • Yes, Kaniko runs in userspace and doesn’t need privileged access or the Docker daemon, making it more secure in multi-tenant environments.

4. Main advantage in CI/CD pipelines?

   • You can build and push container images in Kubernetes pods without exposing the Docker socket or running privileged containers.

5. Where can Kaniko build images?

   • Kaniko is typically run inside Kubernetes pods, but can also run in other containerized environments.

🛠️ Intermediate Level

6. How does Kaniko build images without a Docker daemon?

   • It parses the Dockerfile and executes commands in a containerized filesystem using user namespaces and the Go standard library to simulate Docker behavior.

7. Kaniko pod components:

   • Primarily uses the executor binary. Optionally, cache layers can be pushed to remote registries for reuse.

8. Limitations of Kaniko:

   • Slower than Docker builds.

   • Limited support for some Dockerfile features (e.g., certain secrets handling).

   • Cannot use buildkit optimizations.

9. How to pass credentials to Kaniko:

   • Use a secret volume mount to provide Docker config.json (/kaniko/.docker/config.json) or use Kubernetes service account IAM in GCP/AWS.

10. .dockerignore support:

• Kaniko supports .dockerignore, but not all ignore patterns are fully respected. Always verify during builds.

🚀 Advanced Level

11. Kaniko caching:

• Uses --cache=true and pushes intermediate layers to a remote registry with --cache-repo. On rebuilds, it reuses unchanged layers.

12. Kaniko vs Buildah vs img vs BuildKit:

• Kaniko: Best for Kubernetes. Daemonless. Secure.

• Buildah: Fine-grained control. Red Hat favored.

• img: Daemonless but less popular now.

• BuildKit: Fastest and most advanced; needs Docker daemon or containerd backend.

13. Secure Kaniko in Kubernetes:

• Run as non-root.

• Use minimal base image.

• Limit network access.

• Use secrets from sealed secrets or external secret managers.

14. When Kaniko is not ideal:

• Complex Dockerfile builds with secret mounts or fast rebuild needs (BuildKit may be better).

• Environments requiring heavy caching and performance optimization.

15. Best practices:

• Use .dockerignore.

• Enable caching with --cache.

• Minimize build context.

• Keep Dockerfile simple and clean.

• Use multi-stage builds.

🧪 Scenario-Based

16. Kaniko in GitLab CI:

kaniko-build:
  image: gcr.io/kaniko-project/executor:latest
  script:
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:latest --oci-layout-path /kaniko/output
  only:
    - main

17. Handling secrets:

• Use build args or environment variables, but prefer mounting secrets as files (e.g., via Kubernetes secrets) and referencing them in the Dockerfile.

18. Optimizing slow builds:

• Enable layer caching.

• Use .dockerignore to exclude unnecessary files.

• Break Dockerfile into efficient layers (cache-friendly).

19. Parallel Kaniko builds:

• Use Kubernetes Jobs with parallelism, or run multiple pods/jobs concurrently in your CI/CD system.

20. Debugging Kaniko builds:

• Add --verbosity=debug flag.

• Log the output to a file.

• Use --single-snapshot to simplify file system tracking.

• Run a Kaniko shell container for manual steps.