• compiler:compile – the compile goal from the compiler plugin is bound to the compile phase
• compiler:testCompile is bound to the test-compile phase
• surefire:test is bound to test phase
• install:install is bound to install phase
• jar:jar and war:war is bound to package phase

What are the Ports being used in Artifactory and why? Create a table and describe it.

Find out which maven goal help you to upload a artifact?

mvn deploy

Find out which gradle tasks help you to upload a artifact?

maven-publish

gradle : Task :artifactoryPublish

A ReplicaSets is a bug fixed version of replica controller and it’s purpose is to maintain a stable set of replica Pods running at any given time.

Working with ReplicaSets with example :

A ReplicaSet is defined with fields, including a selector that specifies how to identify Pods it can acquire, a number of replicas indicating how many Pods it should be maintaining, and a pod template specifying the data of new Pods it should create to meet the number of replicas criteria. A ReplicaSet then fulfills its purpose by creating and deleting Pods as needed to reach the desired number. When a ReplicaSet needs to create new Pods, it uses its Pod template.

vi rs.yaml
kubectl create -f rs.yaml
kubectl get rs
[root@swetha swetha]# kubectl get rs
NAME                 DESIRED   CURRENT   READY   AGE
replicaset-example   2         2         2       5s
kubectl get pods
kubectl edit rs replicaset-example
kubectl get pods
vi rs.yaml
kubectl apply -f rs.yaml
kubectl get pods
kubectl scale --replicas=2 -f rs.yaml
kubectl get pods
kubectl scale --replicas=3 rs/replicaset-example
kubectl get pods
kubectl delete rs replicaset-example
kubectl get pods

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  # Unique key of the ReplicaSet instance
  name: replicaset-example
spec:
  # 3 Pods should exist at all times.
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      # Run the nginx image
      - name: nginx
        image: scmgalaxy/nginx-devopsschoolv1

What is DaemonSets ?

A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created.

Working with DaemonSets with example :

A DaemonSet ensures that all eligible nodes run a copy of a Pod. Normally, the node that a Pod runs on is selected by the Kubernetes scheduler. However, DaemonSet pods are created and scheduled by the DaemonSet controller instead. Depending on the requirement, you can set up multiple DaemonSets for a single type of daemon, with different flags, memory, CPU, etc. that supports multiple configurations and hardware types.

The apiVersion, kind, and metadata are required fields in every Kubernetes manifest. The DaemonSet specific fields come under the spec section.

vi ds.yml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  # Unique key of the DaemonSet instance
  name: daemonset-example
  namespace: test-daemonset
spec:
  # 3 Pods should exist at all times.
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      # Run the nginx image
      - name: nginx
        image: scmgalaxy/nginx-devopsschoolv1
[root@swetha swetha]# kubectl get daemonsets
NAME                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset-example   1         1         1       1            1           <none>          5m15s
[root@swetha swetha]# kubectl get pods
NAME                      READY   STATUS    RESTARTS   AGE
daemonset-example-b9jkl   1/1     Running   0          86s
kubectl edit daemonsets daemonset-example
vi ds.yaml
kubectl apply -f ds.yaml
kubectl get pods
kubectl delete daemonsets daemonset-example

What is Statefulsets ?

StatefulSet is the workload API object used to manage stateful applications. Manages the deployment and scaling of a set of pods and provides guarantees about the ordering and uniqueness of these Pods.

Working with Statefulsets with example :

StatefulSets are valuable for applications that require one or more of the following.

• Stable, unique network identifiers.
• Stable, persistent storage.
• Ordered, graceful deployment and scaling.
• Ordered, automated rolling updates.

In the below example:

• A Headless Service, named nginx, is used to control the network domain.
• The StatefulSet, named web, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
• The volumeClaimTemplates will provide stable storage using PersistentVolumes provisioned by a PersistentVolume Provisioner.

The name of a StatefulSet object must be a valid DNS subdomain name

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

What is Service ?

A Service in Kubernetes is an abstraction which defines a logical set of Pods (which performs same function) and a policy by which to access them. A service is responsible for enabling network access to a set of pods.

Working of Services with example :

Services match a set of pods using labels and selectors

Although each Pod has a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a type in the ServiceSpec:

• ClusterIP (default) – Exposes the Service on an internal IP in the cluster. This service is only reachable from within the cluster.
• NodePort – Exposes the Service on the same port of each selected Node in the cluster which makes a Service accessible from outside the cluster.
• LoadBalancer – Exposes the service via the cloud provider’s load balancer and assigns a fixed, external IP to the Service.
• ExternalName – Maps the Service to the contents of the externalName field, by returning a CNAME record with its value.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

This specification creates a new Service object named “my-service”, which targets TCP port 9376 on any Pod with the app=MyApp label. Kubernetes assigns this Service an IP address (sometimes called the “cluster IP”), which is used by the Service proxies. The controller for the Service selector continuously scans for Pods that match its selector, and then POSTs any updates to an Endpoint object also named “my-service”.

What is Load balancers and how do they work ?

Load balancing is defined as the methodical and efficient distribution of network or application traffic across multiple servers in a server farm. Each load balancer sits between client devices and backend servers, receiving and then distributing incoming requests to any available server capable of fulfilling them. Load balancers detect the health of back end resources and do not send traffic to servers that are not able to fulfill request.

A load balancer disburses traffic to different web servers in the resource pool to ensure that no single server becomes overworked and subsequently unreliable. Load balancers effectively minimize server response time and maximize throughput.

Types of Load balancers –

a.) Hardware Load Balancers: physical, on-premise, hardware equipment to distribute the traffic on various servers. Though they are capable of handling a huge volume of traffic but are limited in terms of flexibility, and are also fairly high in prices.

b.) Software Load Balancers: computer applications that need to be installed in the system and function similarly to the hardware load balancers. They are of two kinds- Commercial and Open Source and are a cost-effective alternative to the hardware counterparts.

c.) Virtual Load Balancers: combination of the program of a hardware load balancer working on a virtual machine.

What is Discovery Services and how it works?

Service discovery takes advantage of the labels and selectors to associate a service with a set of pods. A single pod or a ReplicaSet may be exposed to internal or external clients via services, which associate a set of pods with a specific criterion. Any pod whose labels match the selector defined in the service manifest will automatically be discovered by the service. This architecture provides a flexible, loosely-coupled mechanism for service discovery.

What is coreDNS ?

CoreDNS is a flexible, extensible DNS server that can serve as the Kubernetes cluster DNS. Like Kubernetes, the CoreDNS project is hosted by the CNCF.

Use of coreDNS –

We can use CoreDNS instead of kube-dns in our cluster by replacing kube-dns in an existing deployment, or by using tools like kubeadm that will deploy and upgrade the cluster for you.

How certificate based Authentication works? Explain in kubernetes context.

– Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to authenticate API requests through authentication plugins
– Client certificates generated by kubeadm expire after 1 year.
– By default, kubeadm generates all the certificates needed for a cluster to run. You can override this behavior by providing your own certificates.
– you must place them in whatever directory is specified by the –cert-dir flag or the certificatesDir field of kubeadm’s ClusterConfiguration. By default this is /etc/kubernetes/pki.
If a given certificate and private key pair exists before running kubeadm init, kubeadm does not overwrite them. This means for example, copy an existing CA into /etc/kubernetes/pki/ca.crt and /etc/kubernetes/pki/ca.key, and kubeadm will use this CA for signing the rest of the certificates.
command : kubeadm certs check-expiration

 User/administrator generates a private key (PK) and certificate signing request (CSR). Administrator approves the request and signs it with their CA. Administrator provides the resulting certificate (CRT) back to the user. User uses private key and certificate to login to API Server.

Admin creates private key –> which is later converts into csr –> Admin take this csr file and CA and create .crt file.

What is Block Storage?

Block storage, sometimes referred to as block-level storage, is a technology that is used to store data files on Storage Area Networks (SANs) or cloud-based storage environments. Developers favor block storage for computing situations where they require fast, efficient, and reliable data transportation.

Block storage breaks up data into blocks and then stores those blocks as separate pieces, each with a unique identifier. The SAN places those blocks of data wherever it is most efficient. That means it can store those blocks across different systems and each block can be configured (or partitioned) to work with different operating systems. Block storage also decouples data from user environments, allowing that data to be spread across multiple environments. This creates multiple paths to the data and allows the user to retrieve it quickly.

How volume plugins in kubernetes works?

Volumes offer storage shared between all containers in a Pod. This allows you to reliably use the same mounted file system with multiple services running in the same Pod. This is, however, not automatic. Containers that want to use a volume have to specify which volume they want to use, and where to mount it in the container’s file system

https://v1-17.docs.kubernetes.io/docs/concepts/storage/volumes/
https://kubernetes.io/docs/concepts/storage/volumes/.

Admin will be creating persistent volume (pv) and users/developers claims that ( persistent volume claim).

What is StorageClass? and How to work with it with sample StorageClass, PV, PVC, POD.yaml ?

A StorageClass provides a way for administrators to describe the “classes” of storage they offer. Different classes might map to quality-of-service levels, or to backup policies, or to arbitrary policies determined by the cluster administrators.
Kubernetes itself is unopinionated about what classes represent.
This concept is sometimes called “profiles” in other storage systems.
A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes.
It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV.
This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources.
Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes.

Each StorageClass contains the fields provisioner, parameters, and reclaimPolicy, which are used when a PersistentVolume belonging to the class needs to be dynamically provisioned.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - debug
volumeBindingMode: Immediate

1. container orchestrator
2. Workload placement
3. Maintains desired state
4. Self-healing
5. Automated rollbacks
6. Auto scaling
7. Load balancing
8. Speed of deployment
9. Ability to absorb change quickly
10. Hide complexity in the cluster

How Kubernetes works ?

Kubernetes are comprised of master and multiple nodes where Master is In-charge of cluster which manages nodes and nodes manages one or multiple pods and pod manages one or multiple containers.

What are the components of Master ?

1. Kube-API server – front end thru which any communication is passed and consumes JSON via manifest files.
2. Kube-Cluster store – requests gets stored in cluster store in key value format powered by etcd.
3. Kube-Controller manager – controller of controllers which watches for changes and helps in maintaining desired state.
4. Kube-Scheduler – watches API server for new pods, assigns work to nodes and interacts with kubelet in node.

What are the components of Worker ?

1. Kubelet – main kubernetes agent which registers node with cluster and instantiates pods, exposes endpoint on: 10255.
2. Container Engine (Docker) – does container management: pulling images and running containers.
3. Kube –proxy – manages kubernetes networking (pod IP addresses), all containers in a pod share a single IP.

What are the components of Workstation ?

Kubectl – CLI to interact with APIserver

What is POD ?

A pod is the smallest execution unit that you can create and manage in Kubernetes. A Pod  is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers.

• A pod encapsulates one or more applications.
• When a pod is created it is assigned its own unique IP address.
• Pods have a single IP address that is applied to every container within the pod.
• Containers in a pod share the same resources such as memory and storage (All containers in pod share the pod environment).
• If there are multiple containers within the pod, they can communicate between each other simply by using localhost. Communications outside of the pod is achieved by exposing a port.
• If a pod (or the node it executes on) fails, Kubernetes can automatically create a new replica of that pod to continue operations.
• Communications between pods in a cluster takes advantage of the fact that Kubernetes assigns a cluster-private IP address to every pod in a cluster, eliminating the need to either explicitly create links between pods or to map container ports to host ports.
• Pods utilize an agent on each node called a kubelet to communicate with the Kubernetes API and the rest of the cluster.
• As the load on a pod increases, Kubernetes can automatically replicate the pod to achieve desired scalability.
• multi-container pods ease deployment configuration compared to setting up shared resources between containers on your own.

[centos@ip-172-31-7-48 ~]$ sudo systemctl start docker
[centos@ip-172-31-7-48 ~]$ history
    1  sudo -s
    2  exit
    3  clear
    4  ls
    5  sudo yum install -y yum-utils device-mapper-persistent-data lvm2
    6   sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
    7   sudo yum install –y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
    8   sudo yum-config-manager --enable rhui-REGION-rhel-server-extras
    9   sudo yum install -y docker-ce
   10  docker -v
   11  sudo systemctl enable docker
   12  sudo systemctl start docker
   13  history

Verify docker installation

[centos@ip-172-31-7-48 ~]$ which docker
/usr/bin/docker
[centos@ip-172-31-7-48 ~]$ which dockerd
/usr/bin/dockerd
[centos@ip-172-31-7-48 ~]$ which containerd
/usr/bin/containerd
[centos@ip-172-31-7-48 ~]$ ps -eaf|grep dockerd
root     10764     1  0 05:16 ?        00:00:00 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
centos   10920  1458  0 05:26 pts/0    00:00:00 grep --color=auto dockerd
[centos@ip-172-31-7-48 ~]$ ps -eaf|grep containerd
root     10753     1  0 05:16 ?        00:00:00 /usr/bin/containerd
root     10764     1  0 05:16 ?        00:00:00 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
centos   10922  1458  0 05:26 pts/0    00:00:00 grep --color=auto containerd
[centos@ip-172-31-7-48 ~]$ docker -v
Docker version 20.10.7, build f0df350
[centos@ip-172-31-7-48 ~]$

Assignment#1

Create Ubuntu Container

[centos@ip-172-31-7-48 ~]$ sudo -s
[root@ip-172-31-7-48 centos]# docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
a31c7b29f4ad: Pull complete
Digest: sha256:b3e2e47d016c08b3396b5ebe06ab0b711c34e7f37b98c9d37abe794b71cea0a2
Status: Downloaded newer image for ubuntu:latest
docker.io/library/ubuntu:latest

[root@ip-172-31-7-48 centos]# docker run -itd ubuntu
49a0ac7cce4a06ca475f26e8e8c27a4b564346cff412e22c394308d7a5397d74
[root@ip-172-31-7-48 centos]# docker ps -a
CONTAINER ID   IMAGE     COMMAND   CREATED         STATUS         PORTS     NAMES
49a0ac7cce4a   ubuntu    "bash"    6 seconds ago   Up 5 seconds             loving_goldwasser

Attaching to the container and Install Update, git & apache2 in ubuntu container

[root@ip-172-31-7-48 centos]# docker attach 49a0ac7cce4a
root@49a0ac7cce4a:/# yum install git
bash: yum: command not found
root@49a0ac7cce4a:/# apt-get update
root@49a0ac7cce4a:/# apt-get install apache2
root@49a0ac7cce4a:/# git --version
git version 2.25.1

Run git command in container from outside

ctrl+p+q - to come out from container
[root@ip-172-31-7-48 centos]# docker exec 49a0ac7cce4a git --version
git version 2.25.1

Assignment#2

Create a httpd container exposed at 8080 port

[root@ip-172-31-7-48 centos]# docker pull httpd
Using default tag: latest
latest: Pulling from library/httpd
Status: Downloaded newer image for httpd:latest
docker.io/library/httpd:latest
[root@ip-172-31-7-48 centos]# docker container run --name web -d -p 8080:80 httpd
3ec7d0b852ee41f4f1fe30ee075b79bdfadf9c4090adcd6945d2411ac5b771c2
[root@ip-172-31-7-48 centos]# docker ps -a
CONTAINER ID   IMAGE     COMMAND              CREATED         STATUS         PORTS                                   NAMES
3ec7d0b852ee   httpd     "httpd-foreground"   6 seconds ago   Up 5 seconds   0.0.0.0:8080->80/tcp, :::8080->80/tcp   web

Access(curl) container from node

[root@ip-172-31-7-48 centos]# curl localhost:8080
<html><body><h1>It works!</h1></body></html>
[root@ip-172-31-7-48 centos]# curl localhost:8081
curl: (7) Failed connect to localhost:8081; Connection refused
[root@ip-172-31-7-48 centos]# curl localhost:8080
<html><body><h1>It works!</h1></body></html>

Assignment#3

Create an image with base – centos and git must be installed in it

[root@ip-172-31-7-48 centos]# touch dockerfile
[root@ip-172-31-7-48 centos]# vi dockerfile
[root@ip-172-31-7-48 centos]# cat dockerfile
FROM ubuntu
MAINTAINER Swetha
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update
RUN apt-get -y install tzdata
RUN apt-get update && apt-get install git -y && apt-get install -yq apache2
CMD /usr/sbin/apache2ctl -D FOREGROUND

[root@ip-172-31-7-48 centos]# docker build -t ub-up-git .
[root@ip-172-31-7-48 centos]# docker images
REPOSITORY   TAG       IMAGE ID       CREATED         SIZE
ub-up-git    latest    c226f4a2cae2   7 minutes ago   259MB
ubuntu       latest    c29284518f49   7 days ago      72.8MB

Push a docker image to hub.docker.com

[root@ip-172-31-7-48 centos]# docker tag ub-up-git swetha97/test21
[root@ip-172-31-7-48 centos]# docker images
REPOSITORY                TAG       IMAGE ID       CREATED          SIZE
swetha97/test21           latest    c226f4a2cae2   16 minutes ago   259MB
ub-up-git-by-dockerfile   latest    c226f4a2cae2   16 minutes ago   259MB
ub-up-git                 latest    c226f4a2cae2   16 minutes ago   259MB
ubuntu                    latest    c29284518f49   7 days ago       72.8MB

[root@ip-172-31-7-48 centos]# docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: swetha97
Password:
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
[root@ip-172-31-7-48 centos]# docker push swetha97/test21

https://hub.docker.com/r/swetha97/test21/tags?page=1&ordering=last_updated