3 ms·

I am leaning toward learning k8s seriously and am actually curious on your take: is the overhead of learning and maintaining a k8s cluster actually better than

I am leaning toward learning k8s seriously and am actually curious on your take: is the overhead of learning and maintaining a k8s cluster actually better than using AWS features like autoscaling coupled with health checks?

ShakataGaNai 7y ago
Don't maintain the cluster. Have someone else run it for you. Unless you want K8s cluster to be the only thing you do. The advantage of K8s is that it abstracts so much away from you, that you should (in theory) be able to take the same YAML config file from AWS EKS to GCP GKE to Azure AKS...and it runs the same everywhere. Things like loadbalancering and HTTP ingress rules that normally would manual configs on each platform - become part of the K8s config.
- xur17 7y ago
  > Don't maintain the cluster. Have someone else run it for you. Unless you want K8s cluster to be the only thing you do. This can be as simple as just using Google's GKE service.
gatherhunterer 7y ago
I find my home cluster to be laughably easy to set up, and I am still new to home clusters. This is an area of rapid development. I could wipe the hard drives and have it back up in less than 30 minutes, not counting the time to rewrite the OS images. I just have some machines running Ubuntu Server with one running Ubuntu Desktop (just because I like it). Each node needs a single shell command and it’s good to go. In the past I have done things like using interface forwarding to allow every node to use a hard drive that is connected to the master so if I ever actually have a use for that or if I want the master to act as a DHCP server and forward its network interface to the workers I can do it again. To maintain portability you need to pay attention to CPU architecture and the underlying OS. Just make sure that your images are built for the same architecture that you will use in the cloud and that you have the right OS and version. x86_64 is ubiquitous (I think AWS offers an ARM server option, though) so developing on a Raspberry Pi cluster might be a headache to deploy. For production you will want to use a cloud provider (or not, it’s not the craziest idea to run a home server if your use case permits) and you can do so for development if you can afford it. The real advantages are service discovery, monitoring options, stateful support and resource allocation. I used Kubernetes Up and Running 2nd Edition, and if you don’t know Docker yet I would work through the Docker Book first because you will want to write your own images. Just make sure that everything lives in the same repository: a single filesystem as the single source of truth.

ShakataGaNai 7y ago

Don't maintain the cluster. Have someone else run it for you. Unless you want K8s cluster to be the only thing you do. The advantage of K8s is that it abstracts so much away from you, that you should (in theory) be able to take the same YAML config file from AWS EKS to GCP GKE to Azure AKS...and it runs the same everywhere. Things like loadbalancering and HTTP ingress rules that normally would manual configs on each platform - become part of the K8s config.

xur17 7y ago
> Don't maintain the cluster. Have someone else run it for you. Unless you want K8s cluster to be the only thing you do. This can be as simple as just using Google's GKE service.

gatherhunterer 7y ago

I find my home cluster to be laughably easy to set up, and I am still new to home clusters. This is an area of rapid development. I could wipe the hard drives and have it back up in less than 30 minutes, not counting the time to rewrite the OS images. I just have some machines running Ubuntu Server with one running Ubuntu Desktop (just because I like it). Each node needs a single shell command and it’s good to go. In the past I have done things like using interface forwarding to allow every node to use a hard drive that is connected to the master so if I ever actually have a use for that or if I want the master to act as a DHCP server and forward its network interface to the workers I can do it again. To maintain portability you need to pay attention to CPU architecture and the underlying OS. Just make sure that your images are built for the same architecture that you will use in the cloud and that you have the right OS and version. x86_64 is ubiquitous (I think AWS offers an ARM server option, though) so developing on a Raspberry Pi cluster might be a headache to deploy. For production you will want to use a cloud provider (or not, it’s not the craziest idea to run a home server if your use case permits) and you can do so for development if you can afford it. The real advantages are service discovery, monitoring options, stateful support and resource allocation. I used Kubernetes Up and Running 2nd Edition, and if you don’t know Docker yet I would work through the Docker Book first because you will want to write your own images. Just make sure that everything lives in the same repository: a single filesystem as the single source of truth.