Posts

KB:CMM (Capability Maturity Model)

Image
The Capability Maturity Model Integration (CMMI) is a set of best practices that helps organizations improve their processes, capabilities, and performance. The model's goal is to create reliable environments where products, services, and departments are efficient, productive, and proactive References:  https://www.ewsolutions.com/fundamentals-capability-maturity-model/ https://en.wikipedia.org/wiki/Capability_Maturity_Model

KB:Claude.ai

Claude AI is a chatbot and generative AI model developed by Anthropic AI, an AI startup, to have natural conversations and perform tasks like summarizing, editing, and answering questions. Claude is designed to be helpful, honest, and harmless, and it incorporates the Constitutional AI model to follow a set of principles when generating responses. Claude is also built with safety and ethics in mind, and it doesn't collect or store personal information  https://claude.ai/chat/a3016232-2956-473c-875c-c763089eea37

KB: Volumes (PersistentVolume) PV and (PersistentVolumeClaim) PVC

Image
Step-1: Create PV (PersistentVolume) Step-2: Create PVC (PersistentVolumeClaim) to bind and claim the storage from PV Things to note: - PVC Binding might fail if the AccessModes are not correct. References: https://dev.to/otomato_io/how-to-use-pre-existing-disk-as-a-k8s-persistent-volume-for-a-gke-cluster-3phd https://kubernetes.io/docs/concepts/storage/persistent-volumes/

KB:Kubernetes POD CPU/RAM Requests and Limits

In Kubernetes, requests and limits manage resources like CPU and memory. Requests ensure a container receives the specified resources by scheduling it on an appropriate node. Limits cap the maximum resources a container can use. The limit must always be equal to or greater than the request, otherwise, Kubernetes will prevent the container from running.   Keep Requests Minimal: Keeping resource requests minimal in Kubernetes is a best practice for optimizing node utilization and reducing costs. By setting minimal requests, you ensure that containers only reserve the resources they truly need, preventing nodes from being underutilized and avoiding unnecessary expenses for over-provisioned resources. This efficient resource management helps in better scheduling and balancing of workloads across the cluster. However, minimal requests do not mean your containers will lack resources. Kubernetes allows containers to use additional resources up to their defined limits if available, ensurin...

K:Kubernetes/Docker EntryPoint and Cmd

  In Docker: ENTRYPOINT : Defines the main command that runs when the container starts. It cannot be easily overridden directly from the command line. CMD : Provides default arguments for the ENTRYPOINT or defines a command to run if no ENTRYPOINT is specified. It can be overridden by passing arguments to docker run . In Kubernetes: command (in the Pod specification): This field overrides the ENTRYPOINT specified in the Dockerfile. args (in the Pod specification): This field overrides the CMD specified in the Dockerfile. Example Dockerfile: Dockerfile FROM ubuntu ENTRYPOINT ["echo"] CMD ["Hello, World!"] Running with Docker: Default behavior: docker run myimage will output Hello, World! . Overriding CMD : docker run myimage Kubernetes will output Kubernetes . Overriding ENTRYPOINT : Not directly possible via command line (requires a change in the Dockerfile or using the --entrypoint flag). Running in Kubernetes: yaml apiVersion: v1 kind: Pod metadata: ...

KB:Kubernetes --dry-run Client vs Server

 The main difference between the two is where the simulation occurs: With --dry-run= client , the simulation happens locally on the client machine before the request is sent to the server. With --dry-run= server , the simulation happens on the server side after the request is sent to the API server. In practice, --dry-run=client is often faster because it doesn't involve communication with the server, but --dry-run=server can provide a more accurate simulation of how the server will handle the request.

KB:Kubernetes run imperative Busybox pod and connect

#buysbox kubectl run -it --rm busybox01 --image=busybox --restart=Never --command -- sh #Network Tools kubectl run -it --rm netshoot --image=nicolaka/netshoot --restart=Never --command -- bash note, busybox image uses "sh" shell, /bin/bash will not work! by design busybox will exit, there is no process/cmd that will run, so you have to connect to the pod/container during run time by overriding the command arg.  kubectl run : This is the command used to create and run a new Pod. -it : This flag is a combination of -i and -t . -i stands for "interactive", which keeps the stdin open even if not attached, and -t stands for "tty", which allocates a TTY (terminal). --rm : This flag tells Kubernetes to automatically remove the Pod once it has finished executing. busybox01 : This is the name of the Pod being created. --image=busybox : This specifies the Docker image to use for the Pod. In this case, it is the busybox image, which is a lightweight Linux distrib...