
UpCloud+Kontena – all Suomi (Finnish) love - saanak
http://blog.kontena.io/upcloud-kontena-all-suomi-love/
======
vim_wannabe
Does anyone know if these Docker+Kontena type of things could be used for
smaller scaled deployments?

I've always wondered if there's an easy way to deploy a Postgres server and a
couple of application servers that would mostly take care of themselves.
Upkeeping standard VPS servers is annoying with all kinds of setup/update SSH
work. Of course you can buy a traditional hosting service from someone but
those are usually restricted to PHP/Mysql. Or you can go with Heroku but then
there's a whole lot of other restrictions. Then there's the full AWS route but
that has a very costly database use/network transfer cost.

In my imagination I would want to set up a Docker script for Postgres, another
Docker script for Nginx and my application, and then push them out to the
internet and have them fend off for themselves. I'm really bad at figuring out
what Kontena etc. does and if they can be used at all for something small like
this, but there's some keywords that I like from the features page:

\- Native support for databases

\- Health checks/automatic restart

\- Let's encrypt support (I can set these up with the docker script too but
seems interesting)

\- Zero-downtime rolling deploys (Not that interesting for me but I guess this
could also mean that it is easy to update my application server?)

\- Logging/monitoring (I guess most vps have this too)

\- Automatic maintenance and security updates

~~~
nevalau
Hi, I'm one of the co-founders of Kontena. Our target from day zero has been
that you can start with small setup and scale up later if needed. So it's
totally okay to run only one node with Kontena. Of course if you want to gain
HA setup, minimum of 3 nodes is recommended.

~~~
vim_wannabe
This definitely sounds interesting. What would my job be after I manage to
make the setup work: Backing up the database?

~~~
nevalau
Yes, backing up the database is one thing. After the setup you can just
concentrate on your applications. Btw we are introducing hosted version of the
Kontena platform soon, which will make the setup even easier. If you are
interested in that option, you can join waiting list already:
[https://www.kontena.io/invite](https://www.kontena.io/invite)

------
jchw
I wonder why I haven't heard of Kontena. It looks pretty good. Currently
running a Kubernetes cluster at work. It's great in many ways but I wish it
had tighter integration with things like Amazon ALB/Route53/etc. Maybe Kontena
will beat it to the punch on some of that?

One complaint: Kontena's FAQ needs some updating.
[https://www.kontena.io/docs/faq.html](https://www.kontena.io/docs/faq.html)

"However, [Kubernetes] does not include overlay networking, DNS, load
balancing, aggregated logging, VPN access or private image repositories"

In fact, it has had all but the last two features built-in and configured by
default since I've started using Kubernetes (version 1.3.) And while having an
integrated private registry is great, it feels like the usefulness is a bit
overstated when configuring one inside of a container environment is already
incredibly easy.

~~~
atombender
The FAQ is arguably correct. Kubernetes doesn't come with overlay networking.
It can work with different clouds, but if you're on, say, DigitalOcean, you
will have to run Flannel or Calico or something similar.

Kubernetes doesn't have DNS built in, but it comes with an add-on you can
install, KubeDNS, which allows internal DNS queries to resolve service names.

Kubernetes doesn't aggregate logs, either. Kubelet knows how to get at Docker
logs, but they're still just sitting in /var/lib/containers somewhere. To
aggregate them, you need to run Fluent or Logspout or similar. If you run
Kubernetes via Google Container Engine, Fluent set up for you (though it will
collect everything into StackDriver Logging, which is not great) through a
daemonset, but it's not built in.

Kubernetes doesn't really have load balancing. You can have it allocate a
cloud LB if you're on GCP or AWS, or you can set up your own Nginx ingress
controller, or some other LB such as Traefik, which integrates nicely with
K8s. For services you get a poor man's load balancing through iptables and
kube-proxy, but it's purely round-robin.

~~~
jchw
I'm a bit late but...

Well, you would be correct to say that Kube-DNS is a "cluster add-on."
However, something being a cluster add-on doesn't make it not part of
Kubernetes. It is no less a part of Kubernetes than kube-proxy. As far as I
can tell, the difference is that cluster add-ons run _within_ the cluster,
alongside other services. With no cherry picking, here is a quick excerpt from
the Kubernetes README about cluster add-ons:

> Cluster add-ons are resources like Services and Deployments (with pods) that
> are shipped with the Kubernetes binaries and are considered an inherent part
> of the Kubernetes clusters.

I do not think there's a standard set of cluster add-ons that are guaranteed
to be installed in any given setup, but thus far I've done a few Kubernetes
deployments and it seems the following come by default anywhere:

\- fluentd for logging (w/ StackDriver on GCE and ELK elsewhere) \- kube-dns
for dns \- grafana + heapster for container metrics \- dashboard (of course)

Re: load balancing. Calling Kubernetes Services poor man's load balancing
seems rather disingenuous. Sure, it's layer 4 load balancing and it is round
robin. However, being lower level does not make it useless. In fact, I have
some production deployments that are not HTTP. Kubernetes does have a
primitive for layer 7 load balancing and routing for HTTP, in the Ingress
resource, which admittedly is not complete yet, but I'm grateful that they
support layer 4 natively. It does just fine with our production deployments
even though it's "purely round robin." Most of the time, pods under the same
service will have roughly equal capacity containers, so round robin is usually
fine. And as far as "poor man's load balancing" goes, it provides liveness and
readiness checking, something that I'd consider to be useful alone, versus say
DNS-based load balancing.

I think in some ways your line of thinking punishes Kubernetes for having a
somewhat modular architecture and that sucks. If you have a setup that
actually does lack ELK or Kube DNS by default with modern versions, then sorry
for misjudging. However, I have not seen this yet and haven't seen anyone use
Kubernetes without Kube DNS since I started.

