Document use cases and process for custom image creation and use in Kubernetes deployments

[rainest]

Summary

Add documentation that covers:

• Creating a custom Kong Docker image from an existing image.
• Uploading a custom image to a registry. Not much to document on our end, but we can link to documentation for major registry providers and must indicate that custom Enterprise images must reside in private registries.
• Configuring manifests to use the custom registry.

Additional Details

Custom images are useful for a variety of purposes, namely:

• Installing custom plugins with library dependencies. These are difficult to handle with ConfigMap mounts due to the way Lua modules work and the way ConfigMaps mount inside containers.
• Adding a custom nginx_kong.lua template. This is necessary for changes that override static values in the standard template. It's possible to do this without building a custom image, but it's often easier to just overwrite the version installed by Kong packages using Docker.
• Making a combination of the above changes and/or OS-level changes (e.g. including internal CA certificates, installing Dynatrace libraries). Sometimes it's just simpler to bundle a bunch of changes into a Docker image build, as there are existing tools for integrating Docker builds and uploads into CD pipelines, and using those instead of manifest-level changes is a valid workflow preference.

Note that while we do provide https://github.com/Kong/docker-kong for building images from scratch (starting from an OS image and installing the Kong package and scripts), guides should focus on building custom image from stock Kong images. Cases for building custom images from scratch do exist, but are less common and more advanced.

@Kong/team-docs draft for this is on us. Ignore it and we'll assign it to someone on the Kubernetes team. Adding the issue to your repo as it doesn't fit cleanly into any of ours, but still needs to live in some GH project (we're moving away from Trello to GH project management).

[mflendrich]

Next step: document possible approaches to users adding plugins/etc. to Kong, so that we can choose the optimal approach before documenting the best known approach today.