5 ms·

Nobody wants to wake up at 1AM because their singly-homed service just went down. Kubernetes might be a fine tool to achieve that, but I want to point out that

Nobody wants to wake up at 1AM because their singly-homed service just went down. Kubernetes might be a fine tool to achieve that, but I want to point out that there are much simpler failover solutions available. Failover is something you should definitely have, but also something you definitely don't need kubernetes for.

zzzcpan 8y ago
In fact, kubernetes won't solve high-availability for you. It is completely orthogonal to failover. EDIT: No, really, k8s won't make a typical RDBMS suddenly able to run in three datacenters across three continents.
- pests 8y ago
  But it can. You can develop a custom controller that does manage a typical RDBMS to be able to run in three datacenters across three continents.
  - pritambaral 8y ago
    > You can develop a custom controller that does manage a typical RDBMS to be able to run in three datacenters across three continents. Honestly, at that point, what does k8s get you? AIUI, Kubernetes is fine for stateless systems, but it is really no better on the storing-state question.
    - wmf 8y ago
      It's easier to install Stolon under K8s than by hand. :-)
    - pests 8y ago
      Consistency.
  - zzzcpan 8y ago
    It was a trick sentence, RDBMSs that can do that and remain useful enough for at least some applications don't exist.
- shaklee3 8y ago
  Huh? One of the core features is making sure you have N pods running at all times. If one fails, it starts another.
  - zzzcpan 8y ago
    This feature won't even work for anything designed for fault tolerance. I believe it can only work for things that either rely on other properly fault tolerant services or that are completely stateless, idempotent, so they can be retried and eventually consistent (in which case the state still has to be handled by properly fault tolerant systems). Either way kubernetes cannot help here.
pacala 8y ago
Name one.
- jontro 8y ago
  We're using elastic beanstalk currently (multi docker conatiner). Not that I'm advocating it and I'm really interested in k8s now that aws has eks, but ebs is really simple to use for a simple setup.
- peterwwillis 8y ago
  Most single-instance, single-zone failover scenarios can be handled with shell scripts, the AWS API, and cron. But the parent's comment is missing the point. K8s is not for failover. K8s is literally just a giant monolith of microservices for running microservices. It's not intended to provide failover for non-microservices, it's intended only to run microservices, and as a side-effect of needing to be able to scale them, it inherently provides some failover mechanisms.
  - pacala 8y ago
    Given GKE or AKS, not quite sure how "shell scripts, the AWS API, and cron" is "much simpler" than: $ docker build . -tag gcr.io/google-samples/hello-app:1.0 $ docker push gcr.io/google-samples/hello-app:1.0 $ kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080 $ kubectl expose deployment hello-server --type "LoadBalancer" where the Dockerfile content is: FROM golang:1.8-alpine ADD . /go/src/hello-app RUN go install hello-app FROM alpine:latest COPY --from=0 /go/bin/hello-app . ENV PORT 8080 CMD ["./hello-app"] https://cloud.google.com/kubernetes-engine/docs/quickstart https://cloud.google.com/kubernetes-engine/docs/quickstart https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/tree/master/hello-app https://github.com/GoogleCloudPlatform/kubernetes-engine-sam...
    - firebacon 8y ago
      The difference in simplicity is not in the interface that is presented to you as a user. The difference is that your shell script will have a couple hundred lines of code, while the docker and kubectl commands from above will pull in literally hundreds of thousands of lines of additional code (and therefore complexity) into your system. I'm not saying that is a bad thing by itself, but there definitely is huge amount of added complexity behind the scenes.

zzzcpan 8y ago

In fact, kubernetes won't solve high-availability for you. It is completely orthogonal to failover. EDIT: No, really, k8s won't make a typical RDBMS suddenly able to run in three datacenters across three continents.

pests 8y ago
But it can. You can develop a custom controller that does manage a typical RDBMS to be able to run in three datacenters across three continents.
- pritambaral 8y ago
  > You can develop a custom controller that does manage a typical RDBMS to be able to run in three datacenters across three continents. Honestly, at that point, what does k8s get you? AIUI, Kubernetes is fine for stateless systems, but it is really no better on the storing-state question.
  - wmf 8y ago
    It's easier to install Stolon under K8s than by hand. :-)
  - pests 8y ago
    Consistency.
- zzzcpan 8y ago
  It was a trick sentence, RDBMSs that can do that and remain useful enough for at least some applications don't exist.
shaklee3 8y ago
Huh? One of the core features is making sure you have N pods running at all times. If one fails, it starts another.
- zzzcpan 8y ago
  This feature won't even work for anything designed for fault tolerance. I believe it can only work for things that either rely on other properly fault tolerant services or that are completely stateless, idempotent, so they can be retried and eventually consistent (in which case the state still has to be handled by properly fault tolerant systems). Either way kubernetes cannot help here.

pacala 8y ago

Name one.

jontro 8y ago
We're using elastic beanstalk currently (multi docker conatiner). Not that I'm advocating it and I'm really interested in k8s now that aws has eks, but ebs is really simple to use for a simple setup.
peterwwillis 8y ago
Most single-instance, single-zone failover scenarios can be handled with shell scripts, the AWS API, and cron. But the parent's comment is missing the point. K8s is not for failover. K8s is literally just a giant monolith of microservices for running microservices. It's not intended to provide failover for non-microservices, it's intended only to run microservices, and as a side-effect of needing to be able to scale them, it inherently provides some failover mechanisms.
- pacala 8y ago
  Given GKE or AKS, not quite sure how "shell scripts, the AWS API, and cron" is "much simpler" than: $ docker build . -tag gcr.io/google-samples/hello-app:1.0 $ docker push gcr.io/google-samples/hello-app:1.0 $ kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080 $ kubectl expose deployment hello-server --type "LoadBalancer" where the Dockerfile content is: FROM golang:1.8-alpine ADD . /go/src/hello-app RUN go install hello-app FROM alpine:latest COPY --from=0 /go/bin/hello-app . ENV PORT 8080 CMD ["./hello-app"] https://cloud.google.com/kubernetes-engine/docs/quickstart https://cloud.google.com/kubernetes-engine/docs/quickstart https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/tree/master/hello-app https://github.com/GoogleCloudPlatform/kubernetes-engine-sam...
  - firebacon 8y ago
    The difference in simplicity is not in the interface that is presented to you as a user. The difference is that your shell script will have a couple hundred lines of code, while the docker and kubectl commands from above will pull in literally hundreds of thousands of lines of additional code (and therefore complexity) into your system. I'm not saying that is a bad thing by itself, but there definitely is huge amount of added complexity behind the scenes.