kubectl describe svc kubernetes

Name:              kubernetes
Namespace:         default
Labels:            component=apiserver
                   provider=kubernetes
Annotations:       <none>
<strong>Selector:          <none></strong>
<strong>Type:              ClusterIP</strong>
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.96.0.1
IPs:               10.96.0.1
Port:              https  443/TCP
TargetPort:        6443/TCP
<strong>Endpoints:         172.31.15.134:6443</strong>
Session Affinity:  None
Events:            <none>

1. ‘kubernetes’ is a clusterIP service. (ie can be accessed only inside the cluster.)
2. It has no selector specified.( So no automatic LB.)
3. But endpoints specified(maybe hardcoded) as 172.31.15.134:6443 ( that means all the requests to this service will be routed to 172.31.15.134:6443)
4. Now you can see the its the IP and port corresponding to APIServer pod.

Conclusion:

So kubernetes service act as a service for APIServer Pod.

Other pods inside the cluster like Scheduler, Controller etc, can use this service to communicate with APIServer pod.

• It is an atomic scheduling unit in a Kubernetes cluster.
• It is a logical unit.
• Every container running in the cluster nodes will be wrapped up by the POD.
• In one POD there can be multiple container running. It is called tight coupling.
• Prefered way is run one container in one POD. It is called loose coupling.
• Each POD will have its own IP address.
• There will be POD nw connecting all the PODS in a cluster irrespective of the nodes.
• Can communicate with each container by <POD IP>:<Container port>
• All the contaniers in a POD can share the POD environment like networking.
• PODs can specify the shared storage volumes and every container in the POD can access it.
• Inside the POD the containers can communicate using localhost.
• Containers with in the POD can also communicate using any IPC mechanism.
• Containers with in different PODs can’t communicate using any IPC mechanism, without some special configuration.
• POD has only two states: Pending and Running.
• PODs can’t be re-deployed. So all the data associated with PODS will be lost once, it is down.

API Server:

• All the incoming/outgoing communication with Kubernetes cluster happening through API Server.
• APIServer is a RESTful server.
• Workstations/Client uses Kubectl tool for communicating with the API Server.
• API Server expects the inputs in JSON format.
• All the communication with the Master node worker nodes are also happening through API Server.
• Scheduler/Controller Manager uses API Server for all the communications with the worker nodes.
• Authentication and authorization.

Etcd:

• This is the storage mechanism Kubernetes Master node has.
• All the details about the cluster configurations and deployments details will be stored in it.
• Stores in key-value format.
• Communicates with API Server only.
• Duties: Config management, Service discovery, Cordinating distributed work.
• With out this we can say Kubernetes cluster is literally dead.

Scheduler:

• Scheduler is responsible for scheduling works to the available pods.
• It intelligently distribute the work to different nodes based on the current work load of the nodes.
• It also consider contraints, available resources etc, before assigning a work.
• Scheduler will provide the self healing fecility on receiving request from controller manager.

Controller Manager:

• Controller manager controlls/monitors the state of each and everything in the cluster.
• It repeatedly checks the health of each nodes and pods.
• It used the watch mechansim provided by the API Server.
• It will communicate with Scheduler if anything went wrong.

Kubelet:

• Resides in each worker nodes.
• Registers the node to the master node.
• Instantiate the Pods.

Container Runtime (Docker):

• For managing and running the containers.

Kube-Proxy:

• It is a nw proxy.
• Implements nw rules on PODS.
• Fecilitate the communication with in the cluster and outside the cluster.
• All the networking related supports are done by this component.
• Can say like a virtual n/w card for the nodes.
• Responsible for assigning IP addresses and all.

• Docker File 1: /usr/sbin/apache2ctl specified in CMD will run in foreground as a blocking call.
• Docker File 2: Just exit after echoing “Hello world”.
• Docker File 3: Just exit after echoing “Hello”.
• Docker File 4: Same as ‘Docker File 1‘ except port 80 will be shown as exposed port.
• Docker File 5: Output will be print like : “Hello /bin/sh -c echo “Hello world””. First it will execute ENTRYPOINT then content of CMD will be passed as an arument that entry point command.

File content:

FROM ubuntu
MAINTAINER Sunil << r.s.sunil@gmail.com>>
CMD "World" 
CMD echo "DOCKER"
ENTRYPOINT ["/bin/echo", "Hello"]
ENTRYPOINT ["/bin/echo", "Welcome to"]

Output:

Welcome to /bin/sh -c echo “DOCKER”

Observations:

• Both CMD and ENTRYPOINT entries will be overwritten with the latest entries.
• That is only the last CMD and ENTRYPOINT will be taken.
• Also the values specified in CMD will be add as an argument to the ENTRYPOINT command.

Dockerfile with 1 CMD, 1 ENTRYPOINT:

File content:

FROM ubuntu
MAINTAINER Sunil << r.s.sunil@gmail.com>>
CMD "World" 
ENTRYPOINT ["/bin/echo", "Hello "]

Output:

Hello World

Observations:

• Values specified in CMD will be add as an argument to the ENTRYPOINT command.

• Docker uses storage drivers to store image layers
• Docker uses storage drivers to store data in the writable layer of a container.
• The container’s writable layer does not persist after the container is deleted, but is suitable for storing temp data generated at runtime.
• Storage drivers are optimized for space efficiency.
• But write speeds are lower than native file system performance.

The Docker Engine provides the following storage drivers on Linux:

docker pull docker
docker pull fluentd
docker pull pypy
docker pull centos
docker pull mongo

Example:

Terminal 1:

root@ip-172-31-28-155:/home/ubuntu# docker wait test_su1

Terminal 2:

root@ip-172-31-28-155:/home/ubuntu# docker stop test_su1

Terminal 1:

root@ip-172-31-28-155:/home/ubuntu# docker wait test_su1
0

We can update the configuration of running/stopped containers except –kernel-memory.

Various Options available.

Use case:

The main usecase is to limit the amount of host resources like CPU, RAM , that can be used by the container.

Docker Unpuase: Resuming the container porcesses.

Normally APPS will do some cleanup activities by handling it.

Docker Kill: Forceful exit. Generate SIGKILL signal.Apps can’t catch or ignore.

A running instance of docker container image.

Docker Container Image:

It is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.

Its basically a collection of file systems. It will have a ROOT FS, USER FS and one or more APP FS.

Can use single container image to run multiple containers.