There's a lot of misleading information here. Pretty much all of his examples use a more difficult solution than needed, making Kubernetes seem like it's a lot more fiddly to use.
> "one docker-compose.yml file ... as opposed to the countless files covering everything"
The author seems to think that a Kubernetes manifest can only contain a single declaration. You can actually stuff as many declarations as you want into a single YAML file, like so (and you should!):
Put it in myapp.yaml and do "kubectl apply -f myapp.yaml". Exactly the same as Docker Compose.
Also, don't use "kubectl create" — use "kubectl apply". It will create or update as needed. It even supports recursing through directories.
> How to use volumes in Kubernetes :(
It's only sad if you use persistent volume claims, which is the "advanced" option which I don't think Swarm even has. I'm not sure why the author felt they needed to use them.
Kubernetes supports ordinary volumes that don't require that you predeclare anything else. For example, on Google Cloud Platform:
This will mount the persistent disk "some-disk-i-created", and automatically format it as ext4 if necessary.
Persistent volume claims are for managing pools of storage: You create one volume, then let pods carve out pieces of it. So you create big, generic volumes and let Kubernetes handle allocation, as opposed to setting up dedicated, named volumes for each container.
There are pros and cons to both approaches, of course. PV/PVCs obviously require that they're defined first. That said, once you've created a PV, it's actually less work to use it across multiple pods, because Kubernetes will handle the gritty details of allocation.
> the fickle beast that is Kubernetes Ingresses ...
In my opinion the ingress system is the weakest part of Kubernetes right now. That said, once you create a controller (nginx-ingress-controller is great, and covers most needs), setting up new ingresses is dead easy, and certainly easier than managing your own load balancer using something like HAProxy or Nginx.
(For simplicity's sake I recommend keeping a single ingress file for your entire system, as opposed to spreading them out among different YAML files. Easier to manage.)
But you don't have to use an ingress or a managed load balancer. It's just a convenience. The way to do it is to use a NodePort, then run your own load balancer that points to it. I don't think this is any different from Docker Swarm. To spread the load across a cluster of containers, you need, per definition, a load balancer. You can also run a Kubernetes-aware load balancer such as Traefik.
> Realising that to use paths i.e. example.com/path ...
The Nginx controller doesn't use physical paths for the ingress endpoints that it proxies. I don't know what he means by this. I have not had this issue.
Hi :),
I did give mention to putting it all in one file in Kubernetes
> You can define everything in one file in Kubernetes but it won't do much for readability.
My emphasis was on how much less config I have to go through to grasp the details of my setup in entirety given a single dense kubernetes config file vs a single compose file.
You mention using kubectl apply to deploy
>Also, don't use "kubectl create" — use "kubectl apply". It will create or update as needed. It even supports recursing through directories.
It is indeed better than kubectl create, however I would point out that if you use it with the intention of running it recursively within a directory, you will have little control over the order of creation of resources, and you will run into errors if one of your resources depends on another resource which has not been created yet.
Before I continue :) you believe that I am using Kubernetes in the most complicated way possible and thus making it seem harder to use than it actually is, however I'd point out that I was porting a "production" cluster to Swarm, and for deployment on dedicated machines and not a generic cloud provider. I therefore had been using whatever advanced options I had at my disposal to make my setup as robust as possible.
7 comments
[ 4.0 ms ] story [ 28.2 ms ] thread> "one docker-compose.yml file ... as opposed to the countless files covering everything"
The author seems to think that a Kubernetes manifest can only contain a single declaration. You can actually stuff as many declarations as you want into a single YAML file, like so (and you should!):
Put it in myapp.yaml and do "kubectl apply -f myapp.yaml". Exactly the same as Docker Compose.Also, don't use "kubectl create" — use "kubectl apply". It will create or update as needed. It even supports recursing through directories.
> How to use volumes in Kubernetes :(
It's only sad if you use persistent volume claims, which is the "advanced" option which I don't think Swarm even has. I'm not sure why the author felt they needed to use them.
Kubernetes supports ordinary volumes that don't require that you predeclare anything else. For example, on Google Cloud Platform:
This will mount the persistent disk "some-disk-i-created", and automatically format it as ext4 if necessary.Persistent volume claims are for managing pools of storage: You create one volume, then let pods carve out pieces of it. So you create big, generic volumes and let Kubernetes handle allocation, as opposed to setting up dedicated, named volumes for each container.
There are pros and cons to both approaches, of course. PV/PVCs obviously require that they're defined first. That said, once you've created a PV, it's actually less work to use it across multiple pods, because Kubernetes will handle the gritty details of allocation.
> the fickle beast that is Kubernetes Ingresses ...
In my opinion the ingress system is the weakest part of Kubernetes right now. That said, once you create a controller (nginx-ingress-controller is great, and covers most needs), setting up new ingresses is dead easy, and certainly easier than managing your own load balancer using something like HAProxy or Nginx.
(For simplicity's sake I recommend keeping a single ingress file for your entire system, as opposed to spreading them out among different YAML files. Easier to manage.)
But you don't have to use an ingress or a managed load balancer. It's just a convenience. The way to do it is to use a NodePort, then run your own load balancer that points to it. I don't think this is any different from Docker Swarm. To spread the load across a cluster of containers, you need, per definition, a load balancer. You can also run a Kubernetes-aware load balancer such as Traefik.
> Realising that to use paths i.e. example.com/path ...
The Nginx controller doesn't use physical paths for the ingress endpoints that it proxies. I don't know what he means by this. I have not had this issue.
> You can define everything in one file in Kubernetes but it won't do much for readability.
My emphasis was on how much less config I have to go through to grasp the details of my setup in entirety given a single dense kubernetes config file vs a single compose file.
You mention using kubectl apply to deploy >Also, don't use "kubectl create" — use "kubectl apply". It will create or update as needed. It even supports recursing through directories.
It is indeed better than kubectl create, however I would point out that if you use it with the intention of running it recursively within a directory, you will have little control over the order of creation of resources, and you will run into errors if one of your resources depends on another resource which has not been created yet.
Before I continue :) you believe that I am using Kubernetes in the most complicated way possible and thus making it seem harder to use than it actually is, however I'd point out that I was porting a "production" cluster to Swarm, and for deployment on dedicated machines and not a generic cloud provider. I therefore had been using whatever advanced options I had at my disposal to make my setup as robust as possible.