Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
keda
KEDA is a Kubernetes-based Event Driven Autoscaling component. It provides event driven scale for any container running in Kubernetes
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
ketch
Ketch is an application delivery framework that facilitates the deployment and management of applications on Kubernetes using a simple command line interface
What does the following refer to in their GitHub readme?
> Caution: Consuming this project can expose you to chemicals, which are known to the State of California to cause cancer and birth defects or other reproductive harm.
https://github.com/acorn-io/acorn/blob/8a474b9e593956c2ad56b...
> How do you determine it's time to scale?
This part is still really hard for a lot of workloads. We have some applications that have a really long startup time (5-10minutes) and also have on the whole predicable traffic patterns. It'd be great to be able to tell k8s to scale up/down based on time of day in addition to the usual metrics without having to resort to a hacky cronjob to adjust the min replicas.
Sure it won't help with a unexpected traffic spike, and it would be better if the applications could come online faster (vendor app out of our control) but most days this feature would allow us to right size the workload way easier.
There's been a few issues like https://github.com/kubernetes/kubernetes/issues/49931 but it doesn't seem to be going anywhere right now
Nomad, Docker Swarm and other solutions support most of these out of the box, Kubernetes is just the most popular and flexible (with which comes a lot of complexity) solution, it seems.
For example, even something as basic as Docker Swarm will see you a lot of the way through.
> How do you implement healthcheck?
Supported by Docker: https://docs.docker.com/engine/reference/builder/#healthchec...
> Does the loadbalancer know how the healthceck is implemented?
When the health checks pass in accordance with the above config, the container state will change from "starting" to "healthy" and traffic will be able to be routed to it. Until then you can have a web server or whatever show a different page/implement circuit breaking or whatever.
> How do you determine it's time to scale?
Docker Swarm doesn't have an abstraction for autoscaling, though there are a few community projects. One can feasibly even write something like that themselves in an evening: https://github.com/jcwimer/docker-swarm-autoscaler
That said, I mostly ignore this concern because I'm yet to see a workload that needs to dynamically scale in any number of private or government projects that I've worked on. Most of the time people want predictable infrastructure and being able to deal with backpressure (e.g. message queue), though that's different with startups.
> How do you implement always-on-process? service unit, initd, cron?
The service abstraction comes out of the box: https://docs.docker.com/engine/swarm/how-swarm-mode-works/se...
You might also want to decide how to best schedule it: wherever available, on a particular node (hostname/tag/...) or on all nodes, which is actually what Portainer agent does! Example: https://docs.portainer.io/start/install/server/swarm/linux
> How do you export the logs?
Docker supports multiple logging drivers: https://docs.docker.com/config/containers/logging/configure/
> How do you inject configs? /etc/environment, profile.d, systemd config, /etc/bestestapp/config?
Docker and Compose/Swarm support environment variables: https://docs.docker.com/compose/compose-file/#environment
If you need config files, you can also use bind mounts: https://docs.docker.com/storage/bind-mounts/
> What about secrets?
Docker supports secrets out of the box: https://docs.docker.com/engine/swarm/secrets/
> Service discovery? Is unbound/bind9?
Docker Swarm supports built in DNS, even allows for multiple separate networks: https://docs.docker.com/engine/swarm/networking/
> These items are best done in a standard way.
Agreed! Though I'd say that the only two options being "running everything on *nix directly" and "running everything in Kubernetes" is a false narrative! The former can work but can also lead to non-standard and error-prone environments with a horrible waste of human resources, whereas the latter can work but can also lead to overcomplicated and hard to debug environments with a horrible waste of human resources.
The best path for many folk probably lies somewhere in the middle, with Nomad/Swarm/Compose/Docker, regardless of what others might claim. The best path for folks interested in a DevOps career is probably running on cloud managed Kubernetes clusters and just using their APIs to lots of great results, not caring about how expensive that is or how easy it would be to self-host on-prem.
> Swarm is deprecated.
I am yet to see this warning when running any workload on Swarm. Feature complete is not necessarily deprecated, Swarm simply won't get any fancy cloud platform integrations due to hype lying elsewhere instead, yet there has been no official word of an EOL, like: https://www.centos.org/centos-linux-eol/
Of course, one can also argue that with the Mirantis acquisition the writing is on the wall and if you care about maximum hireability, then you should grok Kubernetes as well.
None of that prevents me from also running Swarm in setups where it makes sense (e.g. a step up from Docker Compose, limited resources, not lots of time for DevOps related stuff etc.).
> I bet Nomad has no future and will surrender in the coming years.
I'm not so sure about this, Nomad integrates nicely in the rest of the HashiStack and it seems that there are plenty of large orgs investing in it, even when they don't need something like Consul or other offerings, due to its simplicity and more active development.
Currently this claim could use more of a factual basis, otherwise it ends up sounding like ".NET will kill Java" or "Linux on the desktop will kill Windows" or something of that variety.
> Using anything but k8s in 2022 is not wise.
If you live exclusively in the cloud and use only managed offerings, that may as well be true.
Otherwise it seems like a clear clash between the arguments of "pick the right tool for the job" and "pick whatever is popular and widely supported". In the deployments I've worked with, Docker Swarm is better for the first claim (limited complexity, low resource usage, easy to use) which matters more than the latter (on-prem). Someone else who runs stuff primarily in the cloud might have the opposite takeaway, due to how widely Kubernetes is supported, even despite the technical complexity or resource usage.
That said, personally I think that the K3s Kubernetes distribution is one of the better options for many of the deployments out there: https://k3s.io/
In addition, tools like Kompose can make moving from Swarm to Kubernetes something that would take less than a day: https://kompose.io/ (or you can just use Helm), but until the day where Swarm will get a clear deprecation notice or I'll have a good reason to put a particular project on Kubernetes (as some already are), I'll just stick with Swarm/Nomad.
Of course, if a team/employer tells you to just use technology X, do that. Or better yet, make running your OCI compatible containers someone else's problem.
> Swarm is deprecated.
I am yet to see this warning when running any workload on Swarm. Feature complete is not necessarily deprecated, Swarm simply won't get any fancy cloud platform integrations due to hype lying elsewhere instead, yet there has been no official word of an EOL, like: https://www.centos.org/centos-linux-eol/
Of course, one can also argue that with the Mirantis acquisition the writing is on the wall and if you care about maximum hireability, then you should grok Kubernetes as well.
None of that prevents me from also running Swarm in setups where it makes sense (e.g. a step up from Docker Compose, limited resources, not lots of time for DevOps related stuff etc.).
> I bet Nomad has no future and will surrender in the coming years.
I'm not so sure about this, Nomad integrates nicely in the rest of the HashiStack and it seems that there are plenty of large orgs investing in it, even when they don't need something like Consul or other offerings, due to its simplicity and more active development.
Currently this claim could use more of a factual basis, otherwise it ends up sounding like ".NET will kill Java" or "Linux on the desktop will kill Windows" or something of that variety.
> Using anything but k8s in 2022 is not wise.
If you live exclusively in the cloud and use only managed offerings, that may as well be true.
Otherwise it seems like a clear clash between the arguments of "pick the right tool for the job" and "pick whatever is popular and widely supported". In the deployments I've worked with, Docker Swarm is better for the first claim (limited complexity, low resource usage, easy to use) which matters more than the latter (on-prem). Someone else who runs stuff primarily in the cloud might have the opposite takeaway, due to how widely Kubernetes is supported, even despite the technical complexity or resource usage.
That said, personally I think that the K3s Kubernetes distribution is one of the better options for many of the deployments out there: https://k3s.io/
In addition, tools like Kompose can make moving from Swarm to Kubernetes something that would take less than a day: https://kompose.io/ (or you can just use Helm), but until the day where Swarm will get a clear deprecation notice or I'll have a good reason to put a particular project on Kubernetes (as some already are), I'll just stick with Swarm/Nomad.
Of course, if a team/employer tells you to just use technology X, do that. Or better yet, make running your OCI compatible containers someone else's problem.
How does this compare against https://porter.run/ ?
this happened very recently
Etcd v3.5.[0-2] is not recommended for production => https://groups.google.com/a/kubernetes.io/g/dev/c/B7gJs88XtQ...
https://github.com/etcd-io/etcd/issues/13766#issuecomment-10...
Here at Suse we looked at https://github.com/theketchio/ketch and the founder for Acorn did some diligence there. Is it a copy?