A: User/administrator generates a certificate signing request (CSR). Administrator approves the request and signs it with their CA. Administrator provides the resulting certificate back to the user. User presents their key and certificate pair to prove their identity.

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

.crt file can be downloaded by user using csr api to confirm identity.

What is Block Storage?

Block storage is a storage scheme in which each volume acts as a separate hard drive, configured by the storage administrator. Data is stored in fixed-size blocks. A unique address serves as the metadata describing each block.

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. As long as the Pod is active, the volume is there, too. However, when you restart the Pod, the volume gets reset.

Create pv.yaml, pvc.yaml (to claim volume), pod.yaml

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

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.

Ex.

- awsElasticBlockStore - AWS Elastic Block Store (EBS)
- azureDisk - Azure Disk
- azureFile - Azure File
- cephfs - CephFS volume
- cinder - Cinder (OpenStack block storage) (deprecated)
- csi - Container Storage Interface (CSI)
- fc - Fibre Channel (FC) storage
- flexVolume - FlexVolume
- flocker - Flocker storage
- gcePersistentDisk - GCE Persistent Disk
- glusterfs - Glusterfs volume
- hostPath - HostPath volume (for single node testing only; WILL NOT WORK in a multi-node cluster; consider using local volume instead)
- iscsi - iSCSI (SCSI over IP) storage
- local - local storage devices mounted on nodes.
- nfs - Network File System (NFS) storage
- photonPersistentDisk - Photon controller persistent disk. (This volume type no longer works since the removal of the corresponding - cloud provider.)
- portworxVolume - Portworx volume
- quobyte - Quobyte volume
- rbd - Rados Block Device (RBD) volume
- scaleIO - ScaleIO volume (deprecated)
- storageos - StorageOS volume
- vsphereVolume - vSphere VMDK volume

A: A ReplicaSet ensures that a specified number of pod replicas are running at any given time. 
How to work with ReplicasSets?

A: A ReplicaSet is linked to its Pods via the Pods’ metadata.ownerReferences field, which specifies what resource the current object is owned by. All Pods acquired by a ReplicaSet have their owning ReplicaSet’s identifying information within their ownerReferences field. It’s through this link that the ReplicaSet knows of the state of the Pods it is maintaining and plans accordingly.
Example of ReplicasSets?

apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# modify replicas according to your case
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
– name: php-redis
image: gcr.io/google_samples/gb-frontend:v3

Assignment – 2

What is DeamonSets?

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.

How to work with DeamonSets?

You can describe a DaemonSet in a YAML file. For example, the daemonset.yaml file below describes a DaemonSet that runs the fluentd-elasticsearch Docker image:

Example of DeamonSets?

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
# this toleration is to have the daemonset runnable on master nodes
# remove it if your masters can’t run pods
– key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
containers:
– name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
– name: varlog
mountPath: /var/log
– name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
– name: varlog
hostPath:
path: /var/log
– name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers

Assignment – 3

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.

How to work with Statefulsets?

Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.

Example of Statefulsets?

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

Assignment – 4
What is Service?

An abstract way to expose an application running on a set of Pods as a network service.

How Service Works?

Kubernetes Pods are created and destroyed to match the state of your cluster. Pods are nonpermanent resources. If you use a Deployment to run your app, it can create and destroy Pods dynamically.

Each Pod gets its own IP address, however in a Deployment, the set of Pods running in one moment in time could be different from the set of Pods running that application a moment later.

This leads to a problem: if some set of Pods (call them “backends”) provides functionality to other Pods (call them “frontends”) inside your cluster, how do the frontends find out and keep track of which IP address to connect to, so that the frontend can use the backend part of the workload?

What are the types of Service?

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

Example Yaml of Service

Assigment5
What is Loadbalancer?

ItsA load balancer is a device / component that acts as a reverse proxy and distributes network or application traffic across a number of servers.

What are the types of Loadbalancer?

Network

Application loadbalancer

How Loadbalancer works?

The former default kube-proxy mode was userspace, which allocates the next available Kubernetes pod using round-robin load distribution on an IP list, and then rotates or otherwise permutes the list. Modern kube-proxy default mode, called iptables, enables sophisticated rule-based IP management. In iptables mode, random selection is the native method for load distribution. In this situation, an incoming request goes to one of a service’s pods that is randomly chosen

Assigment6
What is Discovery Services?

Service discovery is the automatic detection of devices and services offered by these devices on a computer network. A service discovery protocol (SDP) is a network protocol that helps accomplish service discovery. Service discovery aims to reduce the configuration efforts required by users and administrators.

How Discovery Services works?

Server-side service discovery allows clients applications to find services through a router or a load balancer. Client-side service discovery allows clients applications to find services by looking through or querying a service registry, in which service instances and endpoints are all within the service registry.

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?

The CoreDNS service pods are deployed on the same master node. When the node is lost, the DNS service is down on the cluster until the pod eviction timeout expires.

1.  optimizes the utilization of resources like CPU and memory through containers
2. allow for efficient distributions of applications across a cluster of nodes
3. Its a tool or platform which focuses on deploying and scheduling containers inside the infrastructure instead of directly utilizing nodes/hosts.
4. Container grouping using pod
5. Self-healing
6. Auto-scalablility
7. DNS management
8. Load balancing
9. Rolling update or rollback
10. Resource monitoring and logging

How kubernetes works? –

Kubernetes keeps track of your container applications that are deployed into the cloud. It restarts orphaned containers, shuts down containers when they’re not being used, and automatically provisions resources like memory, storage, and CPU when necessary

What are the components of Master? explain in one line sentense –

Cluster store, controller, apiserver

What are the components of Worker? explain in one line sentense –

pod, docker, kublet, kube-proxy

What are the components of Workstation? explain in one line

control plane, kube-apiserver, scheduler, controller manager, etcd, node, load balancer

Run ‘docker COMMAND –help’ for more information on a command.

[root@ip-172-31-10-74 centos]# clear
[root@ip-172-31-10-74 centos]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
[root@ip-172-31-10-74 centos]# docker info
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 1.13.1
Storage Driver: overlay2
Backing Filesystem: xfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: journald
Cgroup Driver: systemd
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: docker-runc runc
Default Runtime: docker-runc
Init Binary: /usr/libexec/docker/docker-init-current
containerd version: (expected: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1)
runc version: 66aedde759f33c190954815fb765eedc1d782dd9 (expected: 9df8b306d01f59d3a8029be411de015b7304dd8f)
init version: fec3683b971d9c3ef73f284f176672c44b448662 (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Security Options:
seccomp
WARNING: You’re not using the default seccomp profile
Profile: /etc/docker/seccomp.json
selinux
Kernel Version: 3.10.0-1062.12.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 3
CPUs: 1
Total Memory: 1.793 GiB
Name: ip-172-31-10-74.ap-south-1.compute.internal
ID: 6W44:M6T7:AYLW:CPEG:24TO:HGF5:4DSJ:DIJW:GNRT:S5XF:IJGN:DEA3
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Registries: docker.io (secure)
[root@ip-172-31-10-74 centos]# docker pull ubuntu
Using default tag: latest
Trying to pull repository docker.io/library/ubuntu …
latest: Pulling from docker.io/library/ubuntu
a31c7b29f4ad: Pull complete
Digest: sha256:b3e2e47d016c08b3396b5ebe06ab0b711c34e7f37b98c9d37abe794b71cea0a2
Status: Downloaded newer image for docker.io/ubuntu:latest
[root@ip-172-31-10-74 centos]#

[root@ip-172-31-10-74 centos]# ps -eaf | grep dockerd
root 19653 1 0 05:12 ? 00:00:02 /usr/bin/dockerd-current –add-runtime docker-runc=/usr/libexec/docker/docker-runc-current –default-runtime=docker-runc –exec-opt native.cgroupdriver=systemd –userland-proxy-path=/usr/libexec/docker/docker-proxy-current –init-path=/usr/libexec/docker/docker-init-current –seccomp-profile=/etc/docker/seccomp.json –selinux-enabled –log-driver=journald –signature-verification=false –storage-driver overlay2
root 28359 1481 0 05:27 pts/0 00:00:00 grep –color=auto dockerd
[root@ip-172-31-10-74 centos]#