ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
DevOps & observability · #kubernetes
Recommendations for designing and deploying admission webhooks in Kubernetes. This page provides good practices and considerations when designing admission webhooks in Kubernetes. This information is intended for cluster operators who run admission webhook servers or third-party applications that mo
Started · 26 Mar 2023, 17:52 UTC
I have installed rabbitmq using helm chart on a kubernetes cluster. The rabbitmq pod keeps restarting. On inspecting the pod logs I get the below error 2020-02-26 04:42:31.582 [warning] <0.314.0> Error while waiting for Mnesia tables: {timeout_waiting_for_tables,[rabbit_durable_queue]} 2020-02-26 04:42:31.582 [info] <0.314.0> Waiting for Mnesia t
Can anyone explain in simple terms what is the difference between deploying Prometheus through Kubernetes operator and Prometheus helm chart or manifest file? The question is not just pertaining to Prometheus alone but in general
After deleting kubernetes cluster with "terraform destroy" I can't create it again anymore. "terraform apply" returns the following error message: Error: Kubernetes cluster unreachable: invalid configuration: no configuration has been provided, try setting KUBERNETES_MASTER environment variable Here is the terraform configuration: terraform { backend "s3" {
I have both helm 2 and helm 3 installed in my localhost. I have created a new chart using helm2 sanket@Admins-MacBook-Pro poc % helm create new Creating new created a chart 'new ' using helm version 2. Now I have deployed the chart using helm version 3 sanket@Admins-MacBook-Pro poc % helm3 install new new --namespace test NAME: new LAST DEPLOYED: Thu Apr 23
I am trying to debug a pod with the status "ImagePullBackOff". The pod is in the namespace minio-operator, but when I try to to describe the pod, it is apparently not found. Why does that happen? [psr-admin@zon-psr-2-u001 ~]$ kubectl get all -n minio-operator NAME READY STATUS RESTARTS AGE pod/minio-operator-5dd99dd858-n6fdj 0/1 ImagepullBackoff 0 7d NAME RE
Finalizers are namespaced keys that tell Kubernetes to wait until specific conditions are met before it fully deletes resources that are marked for deletion. Finalizers alert controllers to clean up resources the deleted object owned. When you tell Kubernetes to delete an object that has finalizers
To exec into a container in a pod, I use the following two commands (note the template flag in the first command trims the output to print just the name of the pods): $ kubectl get pods --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' app-api-6421cdf4fd-x9tbk app-worker-432f86f54-fknxw app-frontend-87dd65d49c-6b4mn app-rabbit-413632c874-s2ptw $
In Kubernetes, some objects are owners of other objects. For example, a ReplicaSet is the owner of a set of Pods. These owned objects are dependents of their owner. Ownership is different from the labels and selectors mechanism that some resources also use. For example, consider a Service that creat
terraform