RSInfoMinds

  Persistent volume (PV) is a piece of storage provided by an administrator in a Kubernetes cluster. When a developer needs persistent storage for an application in the cluster, they request that storage by creating a persistent volume claim (PVC) and then mounting the volume to a path in the pod Once that is done, the pod claims any volume that matches its requirements (such as size, access mode, and so on).  An administrator can create multiple PVs with different capacities and configurations.  It is up to the developer to provide a PVC for storage, and then Kubernetes matches a suitable PV with the PVC.  If there is no PV to match the PVC, the StorageClass dynamically creates a PV and binds it to the PVC.  It is important to note that Kubernetes does not restrict PVs to a namespace, which means that a pod in any namespace can claim a PV for storage. I am trying to create a pod with volume. But not creating a volume at first sight.  root@master:/kube# kub...

This deployment is widely used across the companies. Its based on ACTIVE/PASSIVE concept. We are going to create a deployment with the image - rajasekar/node-web-v1 of 3 replicas and bind to a service IP. Next, We are going to create another deployment with the image rajasekar/node-web-v2 and enable this deployment in the service IP - aka IP cutover. Make a note of the labels I am using in the deployment: app: nodejs and version: "1.0" apiVersion: apps/v1 kind: Deployment metadata:   name: node-app-v1   labels:     app: node-app spec:   replicas: 3   selector:     matchLabels:       app: nodejs       version: "1.0"   template:     metadata:       labels:         app: nodejs         version: "1.0"     spec:       containers:       - name: nodejs-v1         image: rajasekar/node-web-v1:latest...

  Now we'll build a simple Node.js web application and package it into a container image.  The application will accept HTTP requests and respond with the hostname of the machine it's running in. root@masterk8s:/kube# mkdir nodejs root@masterk8s:/kube# cd nodejs/ root@masterk8s:/kube/nodejs# vi app.js root@masterk8s:/kube/nodejs# cat app.js const http = require('http'); const os = require('os'); console.log("My server starting and listening on 8080..."); var handler = function(request, response) {   console.log("Received request from " + request.connection.remoteAddress);   response.writeHead(200);   response.end("You've hit " + os.hostname() + "\n"); }; var www = http.createServer(handler); www.listen(8080); root@masterk8s:/kube/nodejs# It starts up an HTTP server on port 8080. The server responds with an HTTP response status code 200 OK and the text "You've hit <hostname>" to every request.  The re...

Pod priority indicates the importance of a pod relative to other pods and queues the pods based on that priority. Pod preemption allows the cluster to evict, or preempt, lower-priority pods so that higher-priority pods can be scheduled if there is no available space on a suitable node Pod priority also affects the scheduling order of pods and out-of-resource eviction ordering on the node. Priority classes can help you control the Kubernetes scheduler decisions to favor higher priority pods over lower priority pods. The Kubernetes scheduler can even preempt (remove) lower priority pods that are running so that pending higher priority pods can be scheduled. By setting pod priority, you can help prevent lower priority workloads from impacting critical workloads in your cluster, especially in cases where the cluster starts to reach its resource capacity. root@masterk8s:~# kubectl describe pod kube-scheduler-masterk8s -n kube-system | grep -i priority Priority:        ...

Metrics Server collects resource metrics from Kubelets and exposes them in Kubernetes apiserver through Metrics API for use by Horizontal Pod Autoscaler and Vertical Pod Autoscaler.  Metrics API can also be accessed by kubectl top, making it easier to debug autoscaling pipelines. Metrics Server is not meant for non-autoscaling purposes. For example, don’t use it to forward metrics to monitoring solutions, or as a source of monitoring solution metrics. In such cases please collect metrics from Kubelet /metrics/resource endpoint directly. Metrics Server offers: A single deployment that works on most clusters. Fast autoscaling, collecting metrics every 15 seconds. Resource efficiency, using 1 mili core of CPU and 2 MB of memory for each node in a cluster. Scalable support up to 5,000 node clusters. Requirements: Metrics Server must be reachable from kube-apiserver by container IP address (or node IP if hostNetwork is enabled). The kube-apiserver must enable an aggregation layer. Nodes...