News for hackers. Stuff that matters.
Re:Teaching Kubernetes by atombender on Sunday February 19, 2017 @01:55PM (#13681229)
> Kubernetes on the other hand needs atleast 12 yml files

You don't need to split your manifests into multiple files. You can use a list:

    apiVersion: v1
    kind: List
    items:
    - apiVersion: extensions/v1beta1
      kind: Deployment
      ...
    - apiVersion: v1
      kind: Service
      ...
    - apiVersion: v1
      kind: ConfigMap
      ...
Edit: Or YAML's "multiple document" syntax:

    apiVersion: extensions/v1beta1
    kind: Deployment
    ...
    ---
    apiVersion: v1
    kind: Service
    ...
    ---
    apiVersion: v1
    kind: ConfigMap
    ...
Then you just use "kubectl apply -f myapp.yml" to create or update.

Re ingress, I agree that it's probably the weakest point of Kubernetes at this point. It's particularly weak when it comes to internal load balancing. When you have lots of services that should only need to be available internally, you'll want to have an internal ingress; I don't know about AWS, but Google Cloud Platform's internal load balancer doesn't support pointing at Kubernetes [1]. I haven't found a better option than to run Traefik as a DaemonSet and rely on round-robin DNS (aka poor man's HA).

[1] https://github.com/kubernetes/ingress/issues/112

Re:Teaching Kubernetes by crb on Sunday February 19, 2017 @02:18PM (#13681365)
Or just put --- between various stanzas in one file: https://kubernetes.io/docs/user-guide/managing-deployments/#...

(Google now has a L3 internal load balancer, but not a L7 LB. It's fair to say that this will be made much easier this year.)

Re:Teaching Kubernetes by andrewstuart2 on Sunday February 19, 2017 @02:37PM (#13681490)
I really think the community ought to adopt this as best practice and actively discourage (or even deprecate) the List type. It's just too much noise and zero benefit IMO over raw slices or serialization as arrays (or document lists for YAML).
Re:Teaching Kubernetes by smarterclayton on Sunday February 19, 2017 @06:39PM (#13682919)
As the author (blame me) of the List type, the primary advantage is it needs no special logic in JSON for processing. New line separated JSON is wierd for a lot of libraries, and in the future we want to have endpoints that allow bulk creation / bulk apply.
Re:Teaching Kubernetes by lobster_johnson on Sunday February 19, 2017 @03:47PM (#13681890)
That's good news. ILB ingress integration is forthcoming, then, I hope?
Re:Teaching Kubernetes by lobster_johnson on Sunday February 19, 2017 @02:26PM (#13681421)
True! I keep forgetting the multi-document support in YAML.
Re:Teaching Kubernetes by sandGorgon on Sunday February 19, 2017 @03:03PM (#13681661)
>I haven't found a better option than to run Traefik as a DaemonSet and rely on round-robin DNS (aka poor man's HA).

you could try linkerd. It is built with precisely this usecase in mind

Also, it was not just a question of number of files. The size of my docker-compose.yml is about 30-40 lines or so.

Re:Teaching Kubernetes by lobster_johnson on Sunday February 19, 2017 @04:47PM (#13682205)
I think Helm [1] looks promising in this regard.

Helm "charts" are templates that generate Kubernetes manifests. To install a chart, you provide values (for which there are defaults). For example, here [2] is the chart for PostgreSQL. The default values are in values.yaml, and the templates for each manifest are in the templates folder.

Conceptually, this even cleaner than Docker Compose, because there's zero data that isn't specific to your install: Everything else defaults to a pre-defined default.

So in the same way that the official PostgreSQL Docker image is general-purpose, you can define a completely general-purpose chart that can be used by anyone. You customize it by providing overrides.

The only downside is that you still end up with Kubernetes manifests. It's not an abstraction, it's an automation tool.

[1] https://helm.sh

[2] https://github.com/kubernetes/charts/tree/master/stable/post...