Docker & Kubernetes

Docker
1. To show running containers: docker container ls
2. When you use docker desktop containers are not created in host OS, it is created in
Linux VM.
3. Docker run command has 3 states (preparing - downloading image, starting, running)
4. To stop container: docker container stop containerId
5. -p 8080:80 - maps TCP port 80 in the container to port 8080 on the Docker host
6. -p 192.168.1.100:8080:80 - maps TCP port 80 in the container to port 8080 on the
Docker host for connections to host IP 192.168.1.100
7. docker container run - - publish 80:80 - - detach nginx (left is port number and it can be
any you want => localhost:80)
8. Docker run –name mongo -d mongo
9. To show all created containers. (whenever container run types then new container
created for same image): docker container ls -a
10. To show logs in container by appname: docker container logs appname
11. To show logs in container by servicename: docker service logs servicename
12.
● Docker Container is a runtime instance of Docker Image
● Docker Service can run one type of Docker Images on various containers

located on different nodes to perform the same functionality.

● Docker Stack consists of multiple Docker Services.

13. To show processes going on in container: docker container top appname

14. Docker container rm containerIds (removes from ls -a all stopped containers otherwise it
will give error for running container or you can use rm -f (force))
15. To show details of one container config: docker container inspect
16. Docker container stats - shows performance status
17. Docker container port containerId - show which port container is listening
18. Docker network ls
19. Docker network inspect
20. Docker network create –driver
21. Docker network connect
22. Docker network disconnect - dynamically removes NIC from a container on specific
virtual network
23. Network host - it gains performance by skipping virtual networks but sacrifices security of
container model
24. Network bridge - default docker virtual network which is NAT’ed behind host ip
25. Network none - removes eth0 and only leaves you with localhost interface in container
26. Network driver - built-in or 3rd party extensions that give you virtual network features
27. docker container run -d --name new_nginx --network my_app_net nginx
28. Docker demon has built-in DNS server that containers use by default (but default bridge
network has not) and every container has default dns name with its name
29. Docker history nginx:latest - shows layers of change made in image
30. Bing Mounting - maps a host file or directory to a container file or directory

Volumes & Bind Mounts

1. Volumes are the preferred mechanism for persisting data generated by and used by Docker
containers. While bind mounts are dependent on the directory structure and OS of the host
machine, volumes are completely managed by Docker. Volumes have several advantages
over bind mounts. In addition, volumes are often a better choice than persisting data in a
container’s writable layer, because a volume does not increase the size of the containers
using it, and the volume’s contents exist outside the lifecycle of a given container.
2. Create volume: docker volume create my-vol
3. List volumes: docker volume ls
4. To add volume to container: docker run -d -it –name devtest -v “$(pwd)”/target:/app
nginx:latest

5. Bind mounts have been around since the early days of Docker. Bind mounts have limited
functionality compared to volumes. When you use a bind mount, a file or directory on the
host machine is mounted into a container. The file or directory is referenced by its absolute
path on the host machine. By contrast, when you use a volume, a new directory is created
within Docker’s storage directory on the host machine, and Docker manages that directory’s
contents. The file or directory does not need to exist on the Docker host already. It is
created on demand if it does not yet exist. Bind mounts are very performant, but they rely on
the host machine’s filesystem having a specific directory structure available. If you are
developing new Docker applications, consider using named volumes instead. You can’t use
Docker CLI commands to directly manage bind mounts.
6. To add bind mounting to container: docker run -d -it –name devtest -- mount type=bind,
source= “$(pwd)”/target, target=/app nginx:latest

Docker Compose
1. To setup volumes/network and start all containers: docker-compose up
2. To stop all containers and remove cont/vol/net: docker-compose down

Docker Swarm (ssh -i dokey root@)

1. docker swarm init - to initialize swarm
● root signing certificate created for our Swarm.
● Certificate is issued for first manager node.
● Join tokens are created.
 ● Raft database created to store CA, configs and secrets:
○ Encrypted by default on disk
○ No need for another key/value system to hold secrets
○ Replicates logs amongst Managers via mutual TLS in control plane
Raft is a protocol that ensures consistency across multiple nodes and create database on disk
and stores configs of first manager on that disk. Swarm built that database to docker and
handles for us. No need for password handling by ourselves or third party apps.
2. docker node ls - to list nodes
3. docker service create is used to create instances (called tasks) of that service running
in a cluster (called swarm) of computers (called nodes). Those tasks are containers of
cource, but not standalone containers. In a sense a service acts as a template when
instantiating tasks.
4. The docker run command creates and starts a container on the local docker host.
5. A docker "service" is one or more containers with the same configuration running
under docker's swarm mode. It's similar to docker run in that you spin up a container.
The difference is that you now have orchestration.
6. There is only one lead amongst all managers
7. Service in swarm replaces docker run.
8. docker service create - return service id
9. docker service ls
10. Replicas 3 / 4 - 4 is the number of specified replicas and 3 is the number of running
replicas
11. docker service ps serviceName - show list of tasks or containers in that service
12. docker service update serviceName –replicas 3 (docker update command works on
running containers without killing them). If you remove one of the containers then
manager will create new one for satisfying 3 replicas.
13. docker service rm servicename. After that docker container ls command can shows
containers of that service because operation is going on backend. But after some time
you will not see that containers.
14. docker swarm init --advertise-addr 172.18.0.19 (init swarm in node)
15. docker node update –role manager node2
16. watch docker service ls (shows runtime container replica change) - watch is in linux
system as default
17. Services talk each other using servicename
18. docker swarm init - - advertise-addr ip-address (used in cloud servers to init swarm)
19. docker node update –role manager node2 (update node 2 from manager node. Will
make status of node2 as reachable)
20. Manager node will have asterisk in front of id column (docker node ls will show)
21. docker swarm join-token manager - will show join to manager commands for other
nodes. It is just rotating keys
22. docker node ps - shows local nodes running which task. Can also specify node in front
of ps
23. docker service ps servicename - shows in which nodes this task is running
24. For adding volume -v is not compatible with services. So has to write like this (-- mount
type=volume, source=db-data, target=/var/lib/postgresql/data)

Overlay Multi-host Networking

1. It is swarm wide bridge network. It is for container-to-container traffic inside a single
Swarm.
2. Choose –driver overlay when creating network (docker network create –driver overlay
networkName
3. Each service can be connected to multiple overlay networks
4. Bridge networks are usually used when your applications run in standalone containers
that need to communicate.
5. Overlay networks connect multiple Docker daemons together and enable swarm
services to communicate with each other.

Routing Mesh
1. Routes ingress (incoming ) packets for a service to proper task.
2. Spans all nodes in swarm
3. Load balances Swarm services across their tasks
4. This is stateless load balancing and is at OSI layer 3 (TCP), not layer 4 (DNS)
5. If you want use stateful load balancer you can use Nginx with routing mesh
6. Two ways this works:
○ container -to-container in an overlay network. For example: one backend service
such as a database has two replicas. Front end service would not talk with the
database from their ip address. It would talk with VIP (virtual ip (private ip inside
virtual network) that ensures load is distributed among services) that Swarm put
in front of all services. Single VIP is assigned to all nodes and VIP distributes the
request among nodes.
○ External traffic incoming to published ports (all nodes listen). Load balancer
deployed in each node. All coming requests will get to node and LB in node will
direct it to service in another node or in it if it has.

Swarm Stacks
1. docker stack deploy rather than docker service create
2. Controls services, volumes, secrets, networks
3. Can not do build command
4. Compose ignores deploy, swarm ignores build
5. docker-compose up - for development env and integration testing
6. docker stack deploy - for prod env
7. docker stack deploy -c (for compose) “yml file” app_name
8. docker stack services app_name - shows with replication
9. docker stack ps app_name – shows in which nodes services run
10. To update stack just update file and then use deploy common again
11. If there are docker-compose.yml and docker-compose.override.yml. Then if you run
docker-compose up then the base file will run first then the override file will run.
12. For running docker-compose.test.yml for CI integration then write
Docker-compose -f docker-compose.yml -f docker-compose.test.yml up -d
13. For running docker-compose.prod.yml for production then write
Docker-compose -f docker-compose.yml -f docker-compose.prod.yml config

Swarm Secrets
1. Swarm Raft DB is encrypted on disk by default
2. Only stored on disk on manager nodes
3. Secrets are first stored in Swarm then assigned to service
4. Only containers in assigned services can see secrets
5. They look like files in container but are actually in-memory file system
6. Docker secret create secret_name secret_file.txt
7. docker service create –name psql –secret psql_user –secret psql_pass -e
POSTGRES_PASSWORD_FILE=/run/secrets/psql_pass -e
POSTGRES_USER_FILE=/run/secrets/psql_user postgres
8. docker service update –secret-rm (remove secret and redeploy container)
9. external : true in compose file means that you have to create secret by cli tool not file
because it is not secure

Stack Service Updates

1. Swarm update command will update each replica and replace it with new one at a time
2. A stack deploy , when pre-existing, will issue service update
3. Just edit the yaml file , then docker stack deploy -c file.yml <stackname>
4. docker service update –image nginx:1.13.1 - will update each replica of service one at a
time

Docker Healthcheck
1. Docker engine will exec’s the command in the container (e.g. curl localhost)
2. It expects exit 0 (OK) or exit 1 (Error)
3. Three container states: starting (30 second by default), healthy, unhealthy
4. Healthcheck status shows up in docker container ls
5. Check last 5 health checks with docker container inspect
6. Stack service will replace tasks if they fail health check
7. Stack service update wait for them before continuing
8. docker container run –name p2 -d –health-cmd=”pg_isready -U postgres | exit 1”
postgres - will create single container with health check status (it will go from starting to
running for long because it will check health status)

Private Docker Registry

1. “Secure by Default”: Docker will not talk to registry without HTTPS
2. Default port 5000
3. Have to enable TLS certificate
4. Run registry image: docker container run -d -p 5000:5000 –name registry registry
5. Re-tag an existing image and push it to your new registry:
● docker tag hello-world 127.0.0.1:5000/hello-world
● docker push 127.0.0.1:5000/hello-world
6. Remove that image from local cache and pull it from new registry
● docker image remove hello-world
● docker image remove 127.0.0.1:5000/hello-world
● docker pull 127.0.0.1:5000/hello-world
7. Re-create registry using a bind mount : docker container run -d -p 5000:5000 –name
registry -v $(pwd)/registry-data:/var/lib/registry registry

Kubernetes
1. Popular container orchestrator
2. Runs on top of docker as a set of apis in containers. But also can run on other
containers that is not docker powered
3. Many clouds provide it to you with gui
4. Many vendors make a distribution of it (own kubernetes like linux distribution) like
rancher. Decide which kubernetes version they use it.
5. Servers + change rate = benefit or orchestration
6. Swarm advantages:
● Swarm is easy to manage/deploy. But kubernetes has more features and
flexibility
● Swarm follows 80/20 rule which means 20 % of kubernetes features and 80 % of
use cases for running apps
● Swarm runs anywhere docker does
● secure by default
● easier to troubleshoot
7. Kubernetes advantages:
● Clouds will manage and deploy kubernetes for you
● Infrastructure vendors are making their own distributions
● Widest adoption and community
● Flexible: covers widest set of use cases
8. Kubectl - CLI to configure kubernetes and manage apps
9. Node - single server in the kubernetes cluster
10. Kubelet - kubernetes agent running on nodes. In swarm there is no agent because
swarm is built-in orchestrator
11. Kube-Proxy - to control the networking. Placed with kubelet in node
12. Control Plane - set of containers that manage the cluster. Includes API server,
scheduler, controller manager, Core DNS, etcd (another product which is distributed
storage system for key values like RAFT in Swarm). It is sometimes called master
13. Scheduler Container - know how and where containers are placed
14. Controller Manager - looks state of the cluster, take orders
15. Pod - one or more containers running together on one Node. Basic unit of deployment is
a pod. Containers are always in pods. You always deploy pods, not containers in
kubernetes.
16. Deployment - Deployment is a specialized term in the context of Kubernetes. It doesn't
necessarily refer to the deployment of applications or services. Rather, a deployment is
a file that defines a pod's desired behavior or characteristics. Pod is lower level than
deployment and replicaset.
17. Controller - for creating / updating pods and other objects. It has many types:
Deployment, ReplicaSet, StatefulSet, DaemonSet, Job, CronJob, etc.
18. Service - does not have any relation with deploying pods like in Swarm. It is a network
endpoint given to a set of pods. Everything else can access that set of pods using the
DNS name and port.
19. Namespace - filtered group of objects in cluster. It is just like a filter, not a security
feature.
20. There are three ways to create pods from the kubectl CLI:
● kubectl run - changing to be only for pod creation like docker run
● kubectl create - create some resources via CLI or YAML like docker create
● kubectl apply - create/update anything via YAML like stack deploy
21. The fundamental question is how to apply all of the K8s objects into the k8s cluster.
There are several ways to do this job.
● Using Generators (run, expose)
● Using Imperative way (create)
● Using Declarative way (apply)
- All of the above ways have a different purpose and simplicity. For instance, If you want
to check quickly whether the container is working as you desired then you might use
Generators .
- If you want to version control the k8s object then it's better to use a declarative way
which helps us to determine the accuracy of data in k8s objects.

Creating Pods and Control with kubectl

1. For creating a pod:
● kubectl run my-nginx –image nginx
● kubectl create deployment my-apache –image httpd
2. List the pods - kubectl get pods
3. List all objects - kubectl get all
4. For scaling replicas. In Control Plane this things happen:
● Deployment updated to 2 replicas.
● ReplicaSet Controller sets pod count to 2
● Control Plane assigns node to pod
● Kubelet sees pod is needed, starts container
● kubectl scale deploy/my-apache –replicas 2
● kubectl scale deployment my-apache –replicas 2
 Pods & Controller

When kubectl run commands executed it creates deployment controller

and manages replicaset
Deployment

ReplicaSet
Pod

Vol NIC
Nginx
Pod

Vol NIC
Nginx
K8S

Docker

5. For deleting created pod - kubectl delete pod/“pod_name”

6. For getting logs in deployment- kubectl logs deployment/my-apache – follow –tail 1
(follow will return real time last log and tail will return only last line)
7. For getting bunch of logs about objects that share the same namespace- kubectl logs -l
run=my-apache
8. For describing the specific pod like inspect in docker. It also pull real time events that
happen in that pod- first run kubectl get pods command to get specific command then
write kubectl describe pod/pod_name
9. For watching pods - kubectl get pods -w
10. If you delete low level abstraction like pod then high level abstraction like deployment or
replicaset will make sure that pod will be recreated. Like delete containers or tasks which
are recreated by service in Swarm. The replicaset will also be created by deployment if
deleted.
11. When you delete deployment it will delete pods and replicasets also.

Exposing Kubernetes Ports

1. To create a service for existing pods: kubectl expose resourcename –port portNumber
(to which app is listening).
2. To get all services: kubectl get service
3. Service: is a stable address for pods, so other things inside or outside of cluster might be
access it. When we create pods they dont get DNS name automatically. We need a
service on top of that existing pods. CoreDNS (DNS Server) allows us to resolve
services by name.
4. There are different types of services:
● ClusterIP (default) - only available in the cluster. One kubernetes set of pods
talks with other set of pods. When you create deployment the ClusterIP service is
created default under kubernetes service name
○ Single, internal virtual IP allocated
○ Only reachable from within cluster (nodes and pods)
● NodePort - Is designed for sth outside outside the cluster to talk to your service
through ip addresses on the node themselves.
○ High port allocated on each node (assigned to this service)
○ Port is open on every node’s IP
○ Anyone can connect (if they can reach node) even if outside 3rd party
vendors.
○ kubectl expose resourcename –port portNumber –type NodePort
○ After create NodePort service then (ex: 8888:32334) means: left port is
port inside cluster and container that listening on. The right side means
expose port on your nodes to outside world. The right port comes from
default range for NodePort (30000 - 32767) inside container cluster. It is
high port means nothing by default in system can be assigned for
conflicting. When you create NodePort it will create ClusteIP for me.
○ These three services are additive, each one creates the above on it:
1. ClusterIP
2. NodePort
3. LoadBalancer
● LoadBalancer
○ Controls a LB endpoint external to the cluster
○ When you create LB then it automatically creates cluster ip and node port
then talks with external systems. (Only available when infra provider gives
you a LB (AWS ELB, etc.)
● ExternalName
○ Is used less often
○ It is not built in. for to use it you have to use external system like cloud
service (AWS ELB). But if you are in docker desktop it provides built-in
LoadBalancer that publishes the –port on localhost. (kubectl expose –
type LoadBalancer)
○ But if you are on kubeadm, minikube, or microk8s there is no built in
LB.You can still run the command like in docker desktop but it will just say
at “pending” (but its NodePort works).
 ○ Does not have anything to do with controlling inbound traffic to your
services. This is more about staff in your cluster needs to talk to outside
services.
○ Adds CNAME DNS record to CoreDNS only
○ So cluster can have resolve external names you may not have control
externally
○ Not used for pods, but for giving a DNS name to use for sth outside
Kubernetes (for ex: when you migrate from external system to your
cluster)
5. After creating ClusterIP service, if we want to curl it the case is: If you are using docker
desktop then pods are in Linux VM not in Host OS. So to curl this service you have to
create another pod in VM then curl it. To run one single pod, the easiest way is this:
kubectl run –generator(type of template) run-pod/v1 tmp-shell (call it tmp-shell) –rm(once
the pod stops remove it) -it(gets shell into the command) –image bretfisher/netshoot(for
curl) - - (space dash dash space means stop looking options and anything after that
command to run) bash. If you are on linux host just write curl [ip of service]:port
Servicename we created becomes past of the DNS name for this service.
6. LoadBalancer forwards to NodePort, NodePort forwards it to ClusterIP.
7. For listing namespaces - kubectl get namespaces
8. Services also have FQDN. Fully Qualified Domain Name -
<hostname>.<namespace>.svc.cluster.local (svc - service, cluster.local - default service
dns name given to your cluster local when you cerate it)
9. Names of resources need to be unique within a namespace, but not across
namespaces.

Kubernetes Management Techniques

1. Run, create, expose - these commands use helper templates called “generators”.
2. Every resource in kubernetes has a specification or “spec”
3. kubectl create deployment sample –image nginx –dry-run -o yaml - here when writing
this command (--dry-run will not issue this command to create deployment, -o means
output, yaml- format of output.It means that when you write this command show me
output of those templates generated in yaml file but not create it). In the case of expose
command, it will say that you have to create service first.
4. run command is just only for creating pods. But create is used for create all type of
resources. In the past with simple run command you could create deployment, pod,
services. But now you create deployment with create and service with the expose
command.
5. If i dont have docker, but have other types such containerD and kubernetes installed.
And just want to create and run pod then can use run command. But is not
recommended for production. Otherwise can use for dev/test or troubleshooting pods.

Declarative Kubernetes YAML

1. create/update resources in a file: kubectl apply -f filename.yaml
 2. create/update a whole directory or yaml: kubectl apply -f myyaml/
3. create/update from a URL (but first curl it for checking url): kubectl apply -f “url”/pod.yml
4. Each file can contain one or more manifests (resources)
5. Each manifest object describes an API object (deployment, job, secret)
6. Each manifest needs four parts (root key: values in the file)
○ apiVersion: we can get API versions the cluster supports: kubectl api-versions
○ kind: we can get a list of resources the cluster supports: kubectl api-resources
○ metadata: only name is required. You give it a name.
○ spec: we can get all the keys each kind spec supports: kubectl explain
services.spec

Dry Run and Diff

7. To show if local yaml file is different from server yaml file: kubectl apply -f “yaml_file” –
dry-run=server
8. To show what has changed between server yaml and local yaml file: kubectl diff -f
“yaml_file”

Labels and Annotations

Labels:
1. Labels go under metadata in your yaml file
2. Labels are simple list of key: value for identifying your resources later by selecting,
grouping or filtering for it
3. Common examples include: tier: frontend, app: api, env: prod, customer: acme.co
4. We can use command filters to filter by labels: kubectl get pods -l app=nginx

Annotations:
5. Labels are very simple, limited in size, meant to describe resource, not meant to hold
complex, large or non-identifying info, which is annotations are used for.
Label Selectors:
6. The “glue” telling Services and Deployments which pods are theirs for creating link with
them.
7. Many resources use Label Selectors to link resource dependencies.
8. You will see these match up in the Service and Deployment YAML.
9. If that matching labeled pod is not deployed it will not allow you run the yaml file
successfully.
10. Use Labels and Selectors to control which pods go to which nodes.

Kubernetes Storage
1. Generally containers in kubernetes like any orchestrator are stateless by default.
2. StatefulSets is a new resource type, making Pods more sticky for making it persistent.
Volumes in Kubernetes:
1. There are 2 types of volumes: Volumes and PersistentVolumes
2. Volumes are tied to the lifecycle of a Pod. All containers in a single Pod can share them.
3. PersistentVolumes are created at the cluster level and outlive a Pod. Separates
storage config from Pod using it. Multiple pods can share them.
4. There is gonna be a separate team for configuring 3rd party storage.
5. CSI plugins are the new way to connect to storage. In the past 3rd party storage vendors
such as AWS, Azure came built in kubernetes as binary.

Ingress
1. None of our Service types work at OSI layer 7 (HTTP).
2. Ingress Controllers (optional) is not built in kubernetes and do this with 3rd party proxies
3. Ingress Controllers are not load balancers.

CRD’s and The Operator Pattern

1. You can add 3rd party Resources and Controllers.
2. This extends Kubernetes API and CLI.