4 ms·

Digital Ocean's managed Kubernetes offering has been great for me. There's lots of potential complexity to K8s, but if you're not managing the cluster and you

Digital Ocean's managed Kubernetes offering has been great for me. There's lots of potential complexity to K8s, but if you're not managing the cluster and you have simple workloads the ratio of "stuff you have to learn" to "benefits you get" is pretty high. You can deploy anything that runs in a container, so it's really good for experimenting and not being tied down to one language or platform. I can add a new service by copying and pasting a yaml file or two and it's up and running within a half hour or so.

jpgvm 4y ago
If you are going down the k8s path and want to learn both a cool config language and make it easier to be able to deploy abitrary things in a more consistent way I suggest checking out Jsonnet and Tanka. This combination allows me to make use of Helm charts, off-the-shelf YAML and custom Jsonnet in a cohesive way. It's probably overkill for personal projects but I picked up the stack in a previous professional role and for me it's scaled down well enough.
- egamirorrim 4y ago
  I'm in the middle of migrating off Tanka's predecessor ksonnet to pure Helm at $work because the migration effort was deemed too challenging :cry: Did you use ksonnet before?
  - jpgvm 4y ago
    I didn't. Before Tanka we had built our own Jsonnet based system that shelled out to kubectl apply, we also had our own Jsonnet libraries. When I started using Tanka I picked up the version of the ksonnet k8s lib that is managed by Grafana now.
727564797069706 4y ago
What's your approach for ensuring that you've sufficiently secured your Kubernetes cluster? I'd go down the same road as you, but I'm worried that I leave my cluster vulnerable as I don't know much about hardening Kubernetes. For example, I know I shouldn't run my apps under privileged user in Docker, but overall I'm not familiar with a managed Kubernetes attack vector.
- capableweb 4y ago
  First step if you're hosting it at home is separating your home connection from your business connection, physically. If you don't have that, do at least two VLANs. Second step, don't expose anything unless you explicitly know what it's for. Start with everything 100% locked down, and only open things up you know want to be open. If you're just hosting a "home" cloud, nothing have to be exposed externally, so expose nothing. Otherwise go service/port by service/port to expose things.
- mjfisher 4y ago
  The Kubernetes nodes and control plane are not something I manage directly. DigitalOcean perform regular upgrades to keep the cluster at a minimum supportable and secure version. They're reasonably sophisticated, and if they can't upgrade the cluster without downtime they'll notify you with what's wrong - which is great, because I don't know much in depth about K8s administration. The configuration you use is pretty explicit about which ports are internal and which are published externally as a service, so it's unlikely you'll get it wrong by accident. Nevertheless, you can still verify that you haven't done anything daft like opened a DB port to the internet by e.g. trying to connect to it. Finally, there's a whole class of difficult administration, hardening and access problems that can come with Kubernetes multi-tenanted operations that you just side-step as a sole administrator/user. You don't need to worry about who has access to which services or namespaces, or what privileges they have via RBAC - it's just you. I'd want to do some really serious research before letting other users launch containers on my cluster, or execute their own code in it; but that's not one of my use-cases, so it's not a problem.

jpgvm 4y ago

If you are going down the k8s path and want to learn both a cool config language and make it easier to be able to deploy abitrary things in a more consistent way I suggest checking out Jsonnet and Tanka. This combination allows me to make use of Helm charts, off-the-shelf YAML and custom Jsonnet in a cohesive way. It's probably overkill for personal projects but I picked up the stack in a previous professional role and for me it's scaled down well enough.

egamirorrim 4y ago
I'm in the middle of migrating off Tanka's predecessor ksonnet to pure Helm at $work because the migration effort was deemed too challenging :cry: Did you use ksonnet before?
- jpgvm 4y ago
  I didn't. Before Tanka we had built our own Jsonnet based system that shelled out to kubectl apply, we also had our own Jsonnet libraries. When I started using Tanka I picked up the version of the ksonnet k8s lib that is managed by Grafana now.

727564797069706 4y ago

What's your approach for ensuring that you've sufficiently secured your Kubernetes cluster? I'd go down the same road as you, but I'm worried that I leave my cluster vulnerable as I don't know much about hardening Kubernetes. For example, I know I shouldn't run my apps under privileged user in Docker, but overall I'm not familiar with a managed Kubernetes attack vector.

capableweb 4y ago
First step if you're hosting it at home is separating your home connection from your business connection, physically. If you don't have that, do at least two VLANs. Second step, don't expose anything unless you explicitly know what it's for. Start with everything 100% locked down, and only open things up you know want to be open. If you're just hosting a "home" cloud, nothing have to be exposed externally, so expose nothing. Otherwise go service/port by service/port to expose things.
mjfisher 4y ago
The Kubernetes nodes and control plane are not something I manage directly. DigitalOcean perform regular upgrades to keep the cluster at a minimum supportable and secure version. They're reasonably sophisticated, and if they can't upgrade the cluster without downtime they'll notify you with what's wrong - which is great, because I don't know much in depth about K8s administration. The configuration you use is pretty explicit about which ports are internal and which are published externally as a service, so it's unlikely you'll get it wrong by accident. Nevertheless, you can still verify that you haven't done anything daft like opened a DB port to the internet by e.g. trying to connect to it. Finally, there's a whole class of difficult administration, hardening and access problems that can come with Kubernetes multi-tenanted operations that you just side-step as a sole administrator/user. You don't need to worry about who has access to which services or namespaces, or what privileges they have via RBAC - it's just you. I'd want to do some really serious research before letting other users launch containers on my cluster, or execute their own code in it; but that's not one of my use-cases, so it's not a problem.