Ask HN: Do's/don'ts of working with Kubernetes you learned through experience?
1–10 of 30 posts
Re: Ask HN: Do's/don'ts of working with Kubernetes you learned through experience?
#2Re: Ask HN: Do's/don'ts of working with Kubernetes you learned through experience?
#3Use namespaces and logically bounded clusters. Get your monitoring, and tracing and a dashboard to visualize this figured out now.
Re: Ask HN: Do's/don'ts of working with Kubernetes you learned through experience?
#4- If you're planning on using GKE, you'll have to expose your apps using Ingress (this way you can use GCP's L7 Load Balancing with HTTPs). However, this architecture has many limits (e.g. a hard limit of 1000 forwarding rules (FW) per project, each ingress creates an FW and k8s ingress can't refer to another namespace), so make sure you use namespaces wisely.
- Try to learn and teach people on your team about requests and limits. If you don't use it carefully, you'll end up wasting a lot of resources. Also, make sure you have Prometheus and Grafana set up, to give you some visibility.
- Setup Heptio's Velero, it's a lifesaver, especially when running in a managed environment where you have no access to etcd. It can be used to backup your whole cluster and migrate workloads between clusters. If, for some reason, you end up deleting a cluster by mistake, it will be easier to recover its workloads using Velero.
Re: Ask HN: Do's/don'ts of working with Kubernetes you learned through experience?
#5Re: Ask HN: Do's/don'ts of working with Kubernetes you learned through experience?
#6DON'T: use it.
To OP- elaborate on what you're actually trying to accomplish
Re: Ask HN: Do's/don'ts of working with Kubernetes you learned through experience?
#7Re: Ask HN: Do's/don'ts of working with Kubernetes you learned through experience?
#8- Deleting or bulk changing something? Always use the flag --record. This way, you can refer back to what you changed using kubectl rollout history. - If you're planning on using GKE, you'll have to expose your apps using Ingress (this way you can use GCP's L7 Load Balancing with HTTPs). However, this architecture has many limits (e.g. a hard limit of 1000 forwarding rules (FW) per project, each ingress creates an FW…
(Yes, it's confusing. Yes, it can be dangerous)
Re: Ask HN: Do's/don'ts of working with Kubernetes you learned through experience?
#9- Deleting or bulk changing something? Always use the flag --record. This way, you can refer back to what you changed using kubectl rollout history. - If you're planning on using GKE, you'll have to expose your apps using Ingress (this way you can use GCP's L7 Load Balancing with HTTPs). However, this architecture has many limits (e.g. a hard limit of 1000 forwarding rules (FW) per project, each ingress creates an FW…
Minor note: you can have multiple ingress resources for the same hostname. This way you can route some paths to some services in a namespace and other paths to other namespaces. (Yes, it's confusing. Yes, it can be dangerous)
After reading this gigantic issue (https://github.com/kubernetes/kubernetes/issues/17088), we gave up and just created another GCP project.
Re: Ask HN: Do's/don'ts of working with Kubernetes you learned through experience?
#10Use tools like kustomize to reduce proliferation of duplicate k8s resource files.
Do make sure you are using health and liveness checks.
Definitely take care to specify resource requests and limits.
Do use annotations to control provider resources, rather than manually tweaking provider resources that are auto generated by basic k8s files with no annotations.
Aggregate your logs.