For some reason many people don’t get such abbreviations: I’ve created an internal library ‘i8r = imagesaver’, explained this abbreviation everywhere, and some 5 years later, as we are transitioning off of it, about 10% of users don’t call it i-eight-r.
Am I missing something? There seems to be very little substance here: No link to the presentation itself, only slides that lay a very ordinary introduction. Mentioning GitHub stars may have been the first red flag
There is a link to the presentation but yeah, there's not much substance in it either, a lot of nuance is skipped over, to the point where I'd consider it just wrong in places.
Some examples:
"Service object - Grouping object that gives you a stable IP (virtual IP) for the pods that have a certain LABEL": yes, you can use a Service to give your service a "stable IP", but that's just one type of Service; and yes, you can use a Service to target pods with a certain label, but selectors can do more than just that. (Also, what is a "virtual IP"?)
"Containers (Docker)" containers != docker
"Containers in a pod share the same IP address (localhost) and port space" this bit has been cribbed from "Kubernetes in action" (chapter 3 "Understanding how containers share the same IP and port space
": "they share the same IP address and port space") but for some reason they've inserted the "(localhost)" bit which is incorrect.
You can probably find better introductions on YouTube. The k8s docs are also quite understandable in themselves.
Kubernetes is weird and unique software. I feel for it to be more like underlying layer, rather than end solution yet I end up using it as a solution, because all layers just add complexity.
At the same time its popularity makes it obvious that competition basically will not exist in the foreseeable future.
I'm not sure that I qualified to judge it, but I feel that Kubernetes has great architecture.
I was astounded when I realized that Kubernetes is super flexible when it comes to its underlying data model and API. At some time I wanted to reimplement it as a data store and I still think that it might make sense. Think about PostgREST but much more mature and flexible. Like you submit CRD which is JSON schema and then you can insert your entities, query them, listen for changes and so on. And organize your application as a set of "controllers" reconciling those entities into some final form. I just didn't see that kind of universal and flexible and successful architectures before. I assume that it exists in some internal projects.
Kubernetes has strictly defined scope and even reduces that over time. It does not do anything with containers or images, it delegates it to CRI plugin with several popular implementations (containerd and crio). It does not do anything with networking, it delegates it to CNI plugin with multiple popular implementations (flannel, calico, cilium just to name a few). It does not do anything to interact with cloud platforms like AWS, etc. It has some conventions about cloud controllers and cloud vendors implement those controllers, providing integration, scaling and other cloud-specific features.
At the same time I'm using Kubernetes "directly". I don't write stuff which generates yamls. I write yamls directly. Sometimes I use templating engines, mostly kustomize, but those do not reduce much work. And deploying simple application requires quite a lot of YAML lines, most of those being boilerplate. For example docker-compose provides super-concise language. I don't need to write any boilerplate, I just write stuff that makes sense. With Kubernetes, I sometimes have a feeling like I'm writing an assembly code instead of compact high-level code.
I feel like Kubernetes was supposed to be used with some great templating, but all we got was helm and kustomize...
It's not a huge issue, but that's probably a main issue for me.
Other than that, I pretty much like Kubernetes and would use it everywhere for production. Even for single server. It has some learning curve, but once I learned it, I like it and wouldn't use, say, docker instead. And I used a lot of docker.
> At the same time its popularity makes it obvious that competition basically will not exist in the foreseeable future.
That'd be a bummer.
To me, Docker Swarm feels like the logical next step after single node Docker Compose deployments - supports networking and multiple nodes, while still using the simple Compose syntax. Sure, it's not as all encompassing as Kubernetes, but it feels like sometimes the latter isn't worth its complexity (if you want to self-host everything), outside of options like K3s.
I'd even say that something like Hashicorp Nomad is pretty nice if you don't have a problem with HCL. Plus, it supports not just containers, which is probably a boon to many: https://developer.hashicorp.com/nomad/docs/drivers
Why? K8s so far had been very well designed piece of mature and battle tested infra software and documentation is awesome. It also removed a lot of headaches over other proprietary junk I had to deal with. While many hopes and dreams are that docker compose or docker swarm would be enough, once your application group ranges above 100 and want less pampering, k8s is unbeatable.
arccy|1 year ago
k8s has a meaning: in k-ubernete-s there are 8 letters between the k and the s.
thomster|1 year ago
ansgri|1 year ago
bruh2|1 year ago
thomster|1 year ago
HL33tibCe7|1 year ago
Some examples:
"Service object - Grouping object that gives you a stable IP (virtual IP) for the pods that have a certain LABEL": yes, you can use a Service to give your service a "stable IP", but that's just one type of Service; and yes, you can use a Service to target pods with a certain label, but selectors can do more than just that. (Also, what is a "virtual IP"?)
"Containers (Docker)" containers != docker
"Containers in a pod share the same IP address (localhost) and port space" this bit has been cribbed from "Kubernetes in action" (chapter 3 "Understanding how containers share the same IP and port space ": "they share the same IP address and port space") but for some reason they've inserted the "(localhost)" bit which is incorrect.
You can probably find better introductions on YouTube. The k8s docs are also quite understandable in themselves.
vbezhenar|1 year ago
At the same time its popularity makes it obvious that competition basically will not exist in the foreseeable future.
I'm not sure that I qualified to judge it, but I feel that Kubernetes has great architecture.
I was astounded when I realized that Kubernetes is super flexible when it comes to its underlying data model and API. At some time I wanted to reimplement it as a data store and I still think that it might make sense. Think about PostgREST but much more mature and flexible. Like you submit CRD which is JSON schema and then you can insert your entities, query them, listen for changes and so on. And organize your application as a set of "controllers" reconciling those entities into some final form. I just didn't see that kind of universal and flexible and successful architectures before. I assume that it exists in some internal projects.
Kubernetes has strictly defined scope and even reduces that over time. It does not do anything with containers or images, it delegates it to CRI plugin with several popular implementations (containerd and crio). It does not do anything with networking, it delegates it to CNI plugin with multiple popular implementations (flannel, calico, cilium just to name a few). It does not do anything to interact with cloud platforms like AWS, etc. It has some conventions about cloud controllers and cloud vendors implement those controllers, providing integration, scaling and other cloud-specific features.
At the same time I'm using Kubernetes "directly". I don't write stuff which generates yamls. I write yamls directly. Sometimes I use templating engines, mostly kustomize, but those do not reduce much work. And deploying simple application requires quite a lot of YAML lines, most of those being boilerplate. For example docker-compose provides super-concise language. I don't need to write any boilerplate, I just write stuff that makes sense. With Kubernetes, I sometimes have a feeling like I'm writing an assembly code instead of compact high-level code.
I feel like Kubernetes was supposed to be used with some great templating, but all we got was helm and kustomize...
It's not a huge issue, but that's probably a main issue for me.
Other than that, I pretty much like Kubernetes and would use it everywhere for production. Even for single server. It has some learning curve, but once I learned it, I like it and wouldn't use, say, docker instead. And I used a lot of docker.
KronisLV|1 year ago
That'd be a bummer.
To me, Docker Swarm feels like the logical next step after single node Docker Compose deployments - supports networking and multiple nodes, while still using the simple Compose syntax. Sure, it's not as all encompassing as Kubernetes, but it feels like sometimes the latter isn't worth its complexity (if you want to self-host everything), outside of options like K3s.
I'd even say that something like Hashicorp Nomad is pretty nice if you don't have a problem with HCL. Plus, it supports not just containers, which is probably a boon to many: https://developer.hashicorp.com/nomad/docs/drivers
thomster|1 year ago
sigmonsays|1 year ago
n_ary|1 year ago
thomster|1 year ago