docker container to talk to Kubernetes Cluster

There could be need to talk to Kubernetest cluster from segregated docker containers. It’s possible to do so:

 

 

build the pipe from the container to the host machine

There are several ways to connect the host machine. the container is running together with the host, behaving like on the same subnet. you can access it through the public IP.

otherwise, more elegantly, you can leverage on host.docker.internal to talk to the host

 

proxy the resources for the Kubernetes cluster

you can start a Kubernetest proxy to talk to the cluster.

kubectl proxy --port=8080 --disable-filter &

 

 

then to talk to the resources in the cluster from the container, you can do

host.docker.internal:8080/api/v1/namespaces/default/services/pod:{port}/proxy/

 

access the parent docker daemon from the container

recently i have a need to build/start/stop some sibling containers (vs docker within docker), the way to do it is to expose a pipelien from the host to the container:

for single container:

docker run -v /var/run/docker.sock:/var/run/docker.sock

for docker compose

services:
container-to-control-other-sibling-containers:
image: xyz
build:
context: .folder/to/the/controller/container/image
ports:
- 5000:5000
volumes:
- ./:/app
- /var/run/docker.sock:/var/run/docker.sock

View at Medium.com

actually the dameon could listen from other host (configuration):
https://docs.docker.com/v17.09/engine/admin/#configure-the-docker-daemon

update dockerfile within docker compose

have encountered some issue with the stale dockerfile. turns out, docker compose actually cache previous builds (this is not stated in the doc).

so to keep it updated, need to run build without cache then bring it up.


docker-compose build --no-cache && docker-compose up

Image vs Containers for Docker

Not many developers explain technologies clearly, either intentionally or incapably. the post here however is one exception:

from: http://blog.codesupport.info/docker-images-vs-containers/

 

IMAGE :- An image is an inert, immutable, file that’s essentially a snapshot of a container. Images are created with the build command, and they’ll produce a container when started with run. Images are stored in a Docker registry such as registry.hub.docker.com. Because they can become quite large, images are designed to be composed of layers of other images, allowing a miminal amount of data to be sent when transferring images over the network.
 CONTAINER :- To use a programming metaphor, if an image is a class, then a container is an instance of a class—a runtime object. Containers are hopefully why you’re using Docker; they’re lightweight and portable encapsulations of an environment in which to run applications.