Read on Twitter
YAML jokes are getting old, so as the FUD around #kubernetes and the cloud native landscape.
How about my "Kubernetes - the good parts" list instead?
How about my "Kubernetes - the good parts" list instead?
My background: DevOps cosultant, on-boarded many devs to #k8s, built internal app platforms the past 4 years.
This thread is here to increase focus. You may have the killer usecase for things I don't speak highly of, but know that this list is for beginners
This thread is here to increase focus. You may have the killer usecase for things I don't speak highly of, but know that this list is for beginners
Basics first: Pods, Deployments, Services, ConfigMaps, Secrets
Use them, know the concepts. Some point you have to debug them anyways.
Use them, know the concepts. Some point you have to debug them anyways.
Ingress: use it, learn it.
A bit obscure first, but controlling from source code how your app is accessed over the web is powerful
A bit obscure first, but controlling from source code how your app is accessed over the web is powerful
YAML: It's fine. Get over it and use it.
It's easy on the eye. Plus some point - when abstractions leak - you will have to use it anyways.
It's easy on the eye. Plus some point - when abstractions leak - you will have to use it anyways.
Jsonnet, ksonnet, or any language to manage the yaml: just don't.
Do it on your own peril, you risk excluding large part of your audience. Don't make me think
Do it on your own peril, you risk excluding large part of your audience. Don't make me think
The manifest: lengthy, repeating boilerplate. Use templating.
But don't invent one, 127 people have done that before you https://docs.google.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vBitZ3giBtac_H8SBw4uxnrsE/edit#gid=0
But don't invent one, 127 people have done that before you https://docs.google.com/spreadsheets/d/1FCgqz1Ci7_VCz_wdh8vBitZ3giBtac_H8SBw4uxnrsE/edit#gid=0
Use Helm for templating.
I don't say use Helm all the way, but up until `helm template` it's a fine system. And feature rich.
I don't say use Helm all the way, but up until `helm template` it's a fine system. And feature rich.
While at Helm. You probably want to use Helm for 3rd party apps. Redis, Postgres whatnot.
You should, but be aware some install the whole universe. That case, look for raw yaml installation instead.
Many are just fine.
And charts are a great source of inspiration.
You should, but be aware some install the whole universe. That case, look for raw yaml installation instead.
Many are just fine.
And charts are a great source of inspiration.
What about Kustomize you may ask.
Use it for one off patches for yaml you don't control.
But don't build a castle on top of it. You risk re-implementing Helm. I've done that.
Use it for one off patches for yaml you don't control.
But don't build a castle on top of it. You risk re-implementing Helm. I've done that.
You say Helm templates are spaghetti? Maybe, but the kind of spaghetti we are used to.
Again, don't make me think. Ever tried writing a Kustomize json patch by heart?
Again, don't make me think. Ever tried writing a Kustomize json patch by heart?
Now that I'm done with Helm vs Kustomize, here is a dog sailing in snow, before you @ me.
To establish a common ground again, I continue with sigs, aka "special interest groups".
#kubernetes is opensource so as its governance. It's just great that we are able to follow the community in such detail. Slack, minutes, recordings of meetings.
Simply awesome
#kubernetes is opensource so as its governance. It's just great that we are able to follow the community in such detail. Slack, minutes, recordings of meetings.
Simply awesome
CRDs and operators: Some are great, some are 
Like https://github.com/nginxinc/nginx-ingress-operator which has the functionality of a Helm chart, except it's a runtime component
Know when to use them. Writing one for your app is probably not a good idea.
Like https://github.com/nginxinc/nginx-ingress-operator which has the functionality of a Helm chart, except it's a runtime component
Know when to use them. Writing one for your app is probably not a good idea.
Service mesh: don't.
I know, it is intriguing to get all those cool features. So if you chose to use it, set time aside to debug things. Things that just worked before, simple things like HTTP and DB calls may break
Linkerd is the lightweight option here.
I know, it is intriguing to get all those cool features. So if you chose to use it, set time aside to debug things. Things that just worked before, simple things like HTTP and DB calls may break
Linkerd is the lightweight option here.
One more about service mesh:
did you know that multi service traces are not generated automatically by adding the service mesh magic dust? https://linkerd.io/2019/08/09/service-mesh-distributed-tracing-myths/
did you know that multi service traces are not generated automatically by adding the service mesh magic dust? https://linkerd.io/2019/08/09/service-mesh-distributed-tracing-myths/
Grafana: An integrated experience in a fragmented space 
They have the three legs of observability: metrics, logs, traces - in one stellar GUI, plus Loki is awesome.
If you rather build your monitoring stack than buy it, it is a must have
They have the three legs of observability: metrics, logs, traces - in one stellar GUI, plus Loki is awesome.
If you rather build your monitoring stack than buy it, it is a must have
GitOps: use it.
While it is not as figured out as the name suggests - there are scaling issues, and lack of tooling to manage higher level concepts..
the field is maturing, and the patterns it unlocks is great for tooling
Full disclosure - I'm involved in this space
While it is not as figured out as the name suggests - there are scaling issues, and lack of tooling to manage higher level concepts..
the field is maturing, and the patterns it unlocks is great for tooling
Full disclosure - I'm involved in this space
cert manager: it's a blessing. Free certs without doing much. Use it
Use managed Kubernetes. Don't bother running it yourself. This is where the most pain and rejection comes from.
If the minimum fee is prohibiting you from using managed, use k3d on a single node to still benefit from the api
If the minimum fee is prohibiting you from using managed, use k3d on a single node to still benefit from the api
TLDR: there is much value just using #k8s and a few more from the landscape. The FUD comes from the complexity layered on top.
If you know how to write a Dockerfile, the basics of k8s yaml and use a managed k8s..you have a service platform. That's it. You don't need to be fancy.
If you know how to write a Dockerfile, the basics of k8s yaml and use a managed k8s..you have a service platform. That's it. You don't need to be fancy.
