4 ms·

If Kubernetes were IPv6 it would just add complexity for newcomers. Its adoption is actually impressive, but still not really something a junior dev or admin kn

by szszrk 5y ago

If Kubernetes were IPv6 it would just add complexity for newcomers. Its adoption is actually impressive, but still not really something a junior dev or admin knows. And they do know basics of IPv4. The whole article is kind of nice, but I don't think Kubernetes itself is that hard. It's large, but after initial shock it's also very logical and well documented. I think people are afraid of k8s because it forces them to actually implement concepts that they ignored and neglected. Suddenly it occurs that they did not understand how storage works (and k8s has nothing new to offer). Or what their network admins were doing when they set up their "VIP" addresses. Watched a large webinar on "kubernetes" just yesterday. It was aimed at developers, had a huge positive response. Presenter basically did not say more then 2-3 sentences on Kubernetes itself. It was all regular concepts that were with us all the time. State/stateless, synchronous/async, tracing, monitoring. It even ignored storage completely yet still people were shocked "how much usefull kubernetes they learned". Kubernetes exposes how much we knew about system architecture, as our poor designs are exposed quickly.

atc 5y ago
talos2110 5y ago
Is there a link maybe?
- szszrk 5y ago
  Please see my other comment. Unfortunately it's Polish only.
victorhooi 5y ago
Second that - any chance there's a link to the webinar?
- szszrk 5y ago
  Well, it was in Polish :) https://m.youtube.com/watch?v=7NXJHM5oetg https://m.youtube.com/watch?v=7NXJHM5oetg It's "How to implement microservice applications on Kubernetes". It's a cool run through many topics, but it barely touches Kubernetes or even clear microservices as I understand it. I find those topics quite universal, thus I chose that example.
sascha_sl 5y ago
Yes and no. There's a tendency in common distributions to pick complex base components to support seldomly used features at the expense of turning K8s from understandable to magic. I can tell you the main modes of operation and how everything fits together with flannel. Ask me to compare Canal to Calico or explain Cilium and I have no idea anymore. These systems also don't explain themselves well either. I have to dig into the code and docs pretty deeply to see it's BGP and eBPF, two technologies I wouldn't expect your average network-literate admin to know. And don't even get me started on Istio.
- sparsely 5y ago
  Istio has lots of support for retrying and recovering from network errors, which is fortunate because adding it to our infra introduced a lot of transient network errors
- hedora 5y ago
  I think this complexity is part of the business model. You either pay the cloud vendor to solve this issue, or you pay enterprise vendors for storage/network licenses, etc. J2EE was similar, from what I saw. In theory, you could run the open source stuff. In practice, IBM and Oracle made $$$ selling and supporting a proprietary version that supposedly worked out of the box.
- xemdetia 5y ago
  I think that's the other thing that's understated too because a lot of these underlying choose-your-own-adventure pieces are also in wildly different levels of maturity when it comes to observing and debug. You can spend a while pursuing one solution only to find one of the pieces simply doesn't have the functionality or it is not achievable or the big thing for me is not able to be secured in any meaningful way or it's a TODO with no sign of completion. That's still the main thing for me that gives me pause, it ends up being very unreliable when you are trying to secure it or simply put walls up around things. Finding out that your Network plugin doesn't support the thing you need is often not obvious until you have put in a massive amount of resources and work and sometimes it's not reconcilable. The idea of k8s is good, and the model is good, but the observability of features and working through the operational costs are still really raw right now and still has a lot of room for growth.
egeozcan 5y ago
> still not really something a junior dev or admin knows I don't think junior devs should deal with k8s but of course, it depends on how your teams are structured. Some people think juniors should get involved in everything to make them able to choose better what they want to specialize on and I agree partially. It's just that, before you touch k8s, you better are already involved in everything, and have good communication with bigger stakeholders.
- szszrk 5y ago
  It's very specific to the company/environment you are in. Plain Kubernetes can be clean and pleasure to work with until you hit level that "sascha_sl" is describing. On conferences I've met a few guys who considered themselves "junior/mid admins" and did all infra (k8s based) AND desktop support for devs in a 40-50 people software houses. Sounds crazy, but some people just don't complicate their lives, like larger companies love to. Some make it a silo and a complex, huge piece of internal IaaS, some just do "fly my dear bird" like on the popular comic [1] You can manage your cluster externally and have an k8s API ready for you with (some of...) popular clouds with barely any knowledge, including ingress on a public facing ip and a DNS pointing to it. A junior can surely do it. "Does it have backups? YES. So it's production ready". [1] https://www.bluelock.com/wp-content/uploads/2017/06/enterprise-vs-startup-journey-to-cloud.png https://www.bluelock.com/wp-content/uploads/2017/06/enterpri...
prmoustache 5y ago
I don't see vanilla kurnetes as complex. It is the whole ecosystem around it that is complex, especially as there are no 2 setups done the same way. Also each third party operator has its own set of pros/cons/limitations/learning curve. This is the reason when you follow a tutorial about how to publish application X using helm on your local kubernetes minikube/k3s whatever setup on your own laptop usually works fine but just doesn't necessarily translate quickly to deploy a production ready working app of your own on your company's managed k8s setup.
raesene9 5y ago
Kubernetes Dual-stack is enabled by default... https://kubernetes.io/docs/concepts/services-networking/dual-stack/ https://kubernetes.io/docs/concepts/services-networking/dual...

by szszrk 5y ago

atc 5y ago

talos2110 5y ago

Is there a link maybe?

szszrk 5y ago
Please see my other comment. Unfortunately it's Polish only.

victorhooi 5y ago

Second that - any chance there's a link to the webinar?

szszrk 5y ago
Well, it was in Polish :) https://m.youtube.com/watch?v=7NXJHM5oetg https://m.youtube.com/watch?v=7NXJHM5oetg It's "How to implement microservice applications on Kubernetes". It's a cool run through many topics, but it barely touches Kubernetes or even clear microservices as I understand it. I find those topics quite universal, thus I chose that example.

sascha_sl 5y ago

Yes and no. There's a tendency in common distributions to pick complex base components to support seldomly used features at the expense of turning K8s from understandable to magic. I can tell you the main modes of operation and how everything fits together with flannel. Ask me to compare Canal to Calico or explain Cilium and I have no idea anymore. These systems also don't explain themselves well either. I have to dig into the code and docs pretty deeply to see it's BGP and eBPF, two technologies I wouldn't expect your average network-literate admin to know. And don't even get me started on Istio.

sparsely 5y ago
Istio has lots of support for retrying and recovering from network errors, which is fortunate because adding it to our infra introduced a lot of transient network errors
hedora 5y ago
I think this complexity is part of the business model. You either pay the cloud vendor to solve this issue, or you pay enterprise vendors for storage/network licenses, etc. J2EE was similar, from what I saw. In theory, you could run the open source stuff. In practice, IBM and Oracle made $$$ selling and supporting a proprietary version that supposedly worked out of the box.
xemdetia 5y ago
I think that's the other thing that's understated too because a lot of these underlying choose-your-own-adventure pieces are also in wildly different levels of maturity when it comes to observing and debug. You can spend a while pursuing one solution only to find one of the pieces simply doesn't have the functionality or it is not achievable or the big thing for me is not able to be secured in any meaningful way or it's a TODO with no sign of completion. That's still the main thing for me that gives me pause, it ends up being very unreliable when you are trying to secure it or simply put walls up around things. Finding out that your Network plugin doesn't support the thing you need is often not obvious until you have put in a massive amount of resources and work and sometimes it's not reconcilable. The idea of k8s is good, and the model is good, but the observability of features and working through the operational costs are still really raw right now and still has a lot of room for growth.

egeozcan 5y ago

> still not really something a junior dev or admin knows I don't think junior devs should deal with k8s but of course, it depends on how your teams are structured. Some people think juniors should get involved in everything to make them able to choose better what they want to specialize on and I agree partially. It's just that, before you touch k8s, you better are already involved in everything, and have good communication with bigger stakeholders.

szszrk 5y ago
It's very specific to the company/environment you are in. Plain Kubernetes can be clean and pleasure to work with until you hit level that "sascha_sl" is describing. On conferences I've met a few guys who considered themselves "junior/mid admins" and did all infra (k8s based) AND desktop support for devs in a 40-50 people software houses. Sounds crazy, but some people just don't complicate their lives, like larger companies love to. Some make it a silo and a complex, huge piece of internal IaaS, some just do "fly my dear bird" like on the popular comic [1] You can manage your cluster externally and have an k8s API ready for you with (some of...) popular clouds with barely any knowledge, including ingress on a public facing ip and a DNS pointing to it. A junior can surely do it. "Does it have backups? YES. So it's production ready". [1] https://www.bluelock.com/wp-content/uploads/2017/06/enterprise-vs-startup-journey-to-cloud.png https://www.bluelock.com/wp-content/uploads/2017/06/enterpri...

prmoustache 5y ago

I don't see vanilla kurnetes as complex. It is the whole ecosystem around it that is complex, especially as there are no 2 setups done the same way. Also each third party operator has its own set of pros/cons/limitations/learning curve. This is the reason when you follow a tutorial about how to publish application X using helm on your local kubernetes minikube/k3s whatever setup on your own laptop usually works fine but just doesn't necessarily translate quickly to deploy a production ready working app of your own on your company's managed k8s setup.

raesene9 5y ago

Kubernetes Dual-stack is enabled by default... https://kubernetes.io/docs/concepts/services-networking/dual-stack/ https://kubernetes.io/docs/concepts/services-networking/dual...