4 ms·

Been a user of DOs beta kubernetes service and it works well. Though I would say the title of the linked article is a bit misleading. It is a Kubernetes as a s

by flurdy 8y ago

Been a user of DOs beta kubernetes service and it works well. Though I would say the title of the linked article is a bit misleading. It is a Kubernetes as a service, like EKS, GKE and AKS. But not vanilla container service a la ECS, Fargate, the former Docker Cloud, etc.

thinkshiv 8y ago
that is correct
barbecue_sauce 8y ago
Container Service as a Service
- dvtrn 8y ago
  works in dev all the way down.
hnbroseph 8y ago
what makes ECS 'vanilla'? i thought it was just a bespoke competitor to K8s.
- politician 8y ago
  Maybe you're thinking of EKS? ECS is an extremely basic scheduler that's closer to Nomad.
  - yebyen 8y ago
    EKS is no more a competitor to K8S than DOK8s is a competitor to K8s. The CNCF Conformance page[1] shows a link to a spreadsheet[2] which indicates there are currently 96 products by 82 different vendors, including 34 hosted platforms like EKS, which are all Kubernetes. ECS on the other hand, is a so-called "vanilla" container service which provides its own abstractions and offers no suite for conformance, or compatibility with other vendors' offerings. I have not heard lots of people say great things about ECS. If I could say one nice thing, it's that there is probably less to learn about ECS than about Kubernetes. [1]: https://www.cncf.io/certification/software-conformance/ https://www.cncf.io/certification/software-conformance/ [2]: https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4EbB_BGCxT_wlxW_xgHVVa23es/edit#gid=0 https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4Eb...
    - layoric 8y ago
      For me, ECS having less to learn was its main appeal. You get integration with AWS load balancers giving zero down time deployment and its API to automate is very straight forward. I set it up 2 years ago and have barely touched it. I evaluated K8s at the same time and after a full day was left completely confused how to do the same thing even if I spent a full werk. ECS has definitely got some oddities mainly in the task definition spec which is most a 1:1 with docket commands but with their own AWS stuff mixed in. Part from that the simplicity vs K8s was its biggest draw card. Lot has happened with K8s in two years I’d imagine, so same choice today might be a different story.
josh_carterPDX 8y ago
Great distinction. Either way it's nice to see DO expand its offerings. Love their service and the team.
tlrobinson 8y ago
Maybe this is a dumb question, but couldn't/shouldn't a KaaS (and other orchestration systems) just be a layer on top of "vanilla" CaaS?
- jopsen 8y ago
  Don't you need to setup network paths? And connect containers to each other.. Then setup/teardown in specific order.. and if you have state, keep a subset of containers alive to avoid loosing state (even if it's replicated).
  - hosh 8y ago
    Kuberneted is designed in a way where stateless pods (collection of containers sharing the same ip and identity) are decoupled from stateful ones. There are concepts designed into K8S that allows components to attempt to self-heal. For example, a pod that requires a postgresql pod to connect to will fail and crash out. The scheduler will start a new one. If the postgresql pod is up by that point, then the rescheduled pod will no longer crash. As far as the network paths, one of the really cool things about pods running inside a k8s cluster is that they can access any of the other pods, even if they are on a different node. However, pods typically reference services (such as postgresql) by dns name. You specify the set of pods that belong to the service by label selector. This allows the pods to come up, tear down, crash, moved to another node, while the service maintains a stable point of contact. It is quite brilliant, and other orchestrators quickly tried to copy it. Stateful workloads are still difficult. Each distributed stateful system has its own way of setup and teardown. What we will probably see are custom Operators designed for each distributed stateful system, coming out over the years.
- james-mcelwain 8y ago
  Kubernetes has worked to not be coupled to Docker (http://cri-o.io http://cri-o.io / https://www.opencontainers.org/ https://www.opencontainers.org/), so in a sense, it already is built on top of a "vanilla" container service.
- derefr 8y ago
  CaaS-es (i.e. "things that present themselves as a Docker daemon or something like it") don't allow you to provision IaaS-level resources like VMs or disks, merely connect your containers to existing resources. When CaaS-es do allow you to provision stuff (like e.g. Hyper.sh does), they do it through a direct IaaS-level API that is separate from the functioning of the CaaS itself. The major cloud providers' deployments of Kubernetes (and other server-side persistent-orchestrator systems, like the venerable CloudFormation) are deeply integrated into the cloud platform they're running on, such that the orchestrator itself can provision resources for a container to run on as part of deploying the container. This becomes important when elastically auto-scaling a container, because each container might need e.g. its own disk, and you can't create them ahead of time if you don't know how many you'll need. This also means that, unlike a CaaS, k8s et al can manage the very cluster that k8s is running on, scaling it out to suit the size of the current/estimated workload. Theoretically, you can bootstrap k8s on top of a vanilla CaaS—this is how minikube installs "using" your local Docker install, and this is how deployable PaaSes like Flynn and Deis work. But this approach doesn't supply k8s with the cloud-specific integration it needs in order to provision stuff. It might work if you're deploying against something with a standardized API like OpenStack; but none of the major cloud providers are compatible with such APIs, and so they need to build their own k8s plugins that call their IaaS-level APIs, to make k8s work on their clouds. Or, to put all that another way: if there were standard IaaS-level APIs for k8s to hook into, Docker (and the CaaSes that either use or emulate it) would just hook into those APIs itself, and there would be no need for a higher orchestration layer.
deleted 8y ago
[deleted]
RSZC 8y ago
Curious - what are some good alternatives to Fargate? Enjoy the ease of use, but more expensive than I'd like for low-to-no traffic side projects
- philtar 8y ago
  Digital Ocean Droplet AWS Micro Instance AWS Lightsail Linode Nanonode Shared Hosting ----- Tons of options for $5 a month.
  - RSZC 8y ago
    Sorry, should've been more specific - looking for the same sort of 'provide a container and we take care of everything else' experience, but ideally for a cheaper price. I know I could get a micro instance and set up ECS on it, but it just seems like such a royal PITA... Also like how my deploy script is basically 'build image; push image; aws ecs update-service'. With my side projects that are running on a droplet, it feels like there's an incredible amount of additional setup that I need to do every time I add an additional project. Add the new site to the reverse proxy, setup a git server I can push to, set up post-receive hooks for the server, etc., etc.
    - vorticalbox 8y ago
      I would look into the first option, Digital ocean's droplets. You deploy a docker container and they handle the rest
      - StavrosK 8y ago
        How do you do that? I only know the traditional "install OS and handle devops yourself" model. Having said that, I got a cheap and rather beefy server on Hetzner and installed Dokku on it, and I couldn't be more satisfied. It's like having my own Heroku for my low-traffic side-projects, almost for free.
- manigandham 8y ago
  GCP has Serverless Containers coming soon: https://cloudplatform.googleblog.com/2018/07/bringing-the-best-of-serverless-to-you.html https://cloudplatform.googleblog.com/2018/07/bringing-the-be... Zeit V1 supports launching containers (but isnt part of V2): https://zeit.co/docs/v1/getting-started/deployment/#docker-deployment https://zeit.co/docs/v1/getting-started/deployment/#docker-d...

by flurdy 8y ago

thinkshiv 8y ago

that is correct

barbecue_sauce 8y ago

Container Service as a Service

dvtrn 8y ago
works in dev all the way down.

hnbroseph 8y ago

what makes ECS 'vanilla'? i thought it was just a bespoke competitor to K8s.

politician 8y ago
Maybe you're thinking of EKS? ECS is an extremely basic scheduler that's closer to Nomad.
- yebyen 8y ago
  EKS is no more a competitor to K8S than DOK8s is a competitor to K8s. The CNCF Conformance page[1] shows a link to a spreadsheet[2] which indicates there are currently 96 products by 82 different vendors, including 34 hosted platforms like EKS, which are all Kubernetes. ECS on the other hand, is a so-called "vanilla" container service which provides its own abstractions and offers no suite for conformance, or compatibility with other vendors' offerings. I have not heard lots of people say great things about ECS. If I could say one nice thing, it's that there is probably less to learn about ECS than about Kubernetes. [1]: https://www.cncf.io/certification/software-conformance/ https://www.cncf.io/certification/software-conformance/ [2]: https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4EbB_BGCxT_wlxW_xgHVVa23es/edit#gid=0 https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4Eb...
  - layoric 8y ago
    For me, ECS having less to learn was its main appeal. You get integration with AWS load balancers giving zero down time deployment and its API to automate is very straight forward. I set it up 2 years ago and have barely touched it. I evaluated K8s at the same time and after a full day was left completely confused how to do the same thing even if I spent a full werk. ECS has definitely got some oddities mainly in the task definition spec which is most a 1:1 with docket commands but with their own AWS stuff mixed in. Part from that the simplicity vs K8s was its biggest draw card. Lot has happened with K8s in two years I’d imagine, so same choice today might be a different story.

josh_carterPDX 8y ago

Great distinction. Either way it's nice to see DO expand its offerings. Love their service and the team.

tlrobinson 8y ago

Maybe this is a dumb question, but couldn't/shouldn't a KaaS (and other orchestration systems) just be a layer on top of "vanilla" CaaS?

jopsen 8y ago
Don't you need to setup network paths? And connect containers to each other.. Then setup/teardown in specific order.. and if you have state, keep a subset of containers alive to avoid loosing state (even if it's replicated).
- hosh 8y ago
  Kuberneted is designed in a way where stateless pods (collection of containers sharing the same ip and identity) are decoupled from stateful ones. There are concepts designed into K8S that allows components to attempt to self-heal. For example, a pod that requires a postgresql pod to connect to will fail and crash out. The scheduler will start a new one. If the postgresql pod is up by that point, then the rescheduled pod will no longer crash. As far as the network paths, one of the really cool things about pods running inside a k8s cluster is that they can access any of the other pods, even if they are on a different node. However, pods typically reference services (such as postgresql) by dns name. You specify the set of pods that belong to the service by label selector. This allows the pods to come up, tear down, crash, moved to another node, while the service maintains a stable point of contact. It is quite brilliant, and other orchestrators quickly tried to copy it. Stateful workloads are still difficult. Each distributed stateful system has its own way of setup and teardown. What we will probably see are custom Operators designed for each distributed stateful system, coming out over the years.
james-mcelwain 8y ago
Kubernetes has worked to not be coupled to Docker (http://cri-o.io http://cri-o.io / https://www.opencontainers.org/ https://www.opencontainers.org/), so in a sense, it already is built on top of a "vanilla" container service.
derefr 8y ago
CaaS-es (i.e. "things that present themselves as a Docker daemon or something like it") don't allow you to provision IaaS-level resources like VMs or disks, merely connect your containers to existing resources. When CaaS-es do allow you to provision stuff (like e.g. Hyper.sh does), they do it through a direct IaaS-level API that is separate from the functioning of the CaaS itself. The major cloud providers' deployments of Kubernetes (and other server-side persistent-orchestrator systems, like the venerable CloudFormation) are deeply integrated into the cloud platform they're running on, such that the orchestrator itself can provision resources for a container to run on as part of deploying the container. This becomes important when elastically auto-scaling a container, because each container might need e.g. its own disk, and you can't create them ahead of time if you don't know how many you'll need. This also means that, unlike a CaaS, k8s et al can manage the very cluster that k8s is running on, scaling it out to suit the size of the current/estimated workload. Theoretically, you can bootstrap k8s on top of a vanilla CaaS—this is how minikube installs "using" your local Docker install, and this is how deployable PaaSes like Flynn and Deis work. But this approach doesn't supply k8s with the cloud-specific integration it needs in order to provision stuff. It might work if you're deploying against something with a standardized API like OpenStack; but none of the major cloud providers are compatible with such APIs, and so they need to build their own k8s plugins that call their IaaS-level APIs, to make k8s work on their clouds. Or, to put all that another way: if there were standard IaaS-level APIs for k8s to hook into, Docker (and the CaaSes that either use or emulate it) would just hook into those APIs itself, and there would be no need for a higher orchestration layer.

deleted 8y ago

[deleted]

RSZC 8y ago

Curious - what are some good alternatives to Fargate? Enjoy the ease of use, but more expensive than I'd like for low-to-no traffic side projects

philtar 8y ago
Digital Ocean Droplet AWS Micro Instance AWS Lightsail Linode Nanonode Shared Hosting ----- Tons of options for $5 a month.
- RSZC 8y ago
  Sorry, should've been more specific - looking for the same sort of 'provide a container and we take care of everything else' experience, but ideally for a cheaper price. I know I could get a micro instance and set up ECS on it, but it just seems like such a royal PITA... Also like how my deploy script is basically 'build image; push image; aws ecs update-service'. With my side projects that are running on a droplet, it feels like there's an incredible amount of additional setup that I need to do every time I add an additional project. Add the new site to the reverse proxy, setup a git server I can push to, set up post-receive hooks for the server, etc., etc.
  - vorticalbox 8y ago
    I would look into the first option, Digital ocean's droplets. You deploy a docker container and they handle the rest
    - StavrosK 8y ago
      How do you do that? I only know the traditional "install OS and handle devops yourself" model. Having said that, I got a cheap and rather beefy server on Hetzner and installed Dokku on it, and I couldn't be more satisfied. It's like having my own Heroku for my low-traffic side-projects, almost for free.
manigandham 8y ago
GCP has Serverless Containers coming soon: https://cloudplatform.googleblog.com/2018/07/bringing-the-best-of-serverless-to-you.html https://cloudplatform.googleblog.com/2018/07/bringing-the-be... Zeit V1 supports launching containers (but isnt part of V2): https://zeit.co/docs/v1/getting-started/deployment/#docker-deployment https://zeit.co/docs/v1/getting-started/deployment/#docker-d...