eicnix

There is a issue open for this too... https://github.com/kubernetes/kubernetes/issues/40476

Encrypted storage isn't as important when you can restrict the access to the secrets. Just because the secrets are in plaintext in etcd doesn't mean everyone can read them.

Then you need a mutual authenticated connection from the api server to etcd + encrypted etcd hard drives + networking policies that only the api-servers are able to communicate with etcd and your secrets are pretty safely stored.

Yes, the kubernetes secrets resource is not a replacement for a secret store. Your specific point is being worked on: https://github.com/kubernetes/kubernetes/issues/12742

You can use Vault(https://github.com/Boostport/kubernetes-vault) or extend Kubernetes easily for your specific secret as a replacement if you need extra security.

Kubernetes supports this already. You have the choice to either mount the secret into the container file system or set it as a environment variable. https://kubernetes.io/docs/user-guide/secrets/#using-secrets...

Kubernetes supported secrets for nearly 2 years: https://kubernetes.io/docs/user-guide/secrets/

They currently debate over pluggable secret stores: https://github.com/kubernetes/kubernetes/issues/10439

You can use Hashicorp Vault as a third party resource to store your secrets: https://github.com/Boostport/kubernetes-vault

Kubernetes also supports RBAC to control access to secrets: https://kubernetes.io/docs/admin/authorization/

From what I understand there are no secruity mechanisms other than authentication to the cluster. How do you prevent somebody that got access to the cluster to just read all your secrets?

Can I plug in my own secret store?

Thank you for the recommendation. I plan to do some testing to setup a kubernetes cluster on bare metal and will try ovh for this aswell.

Interesting point. In my experience buy vs rent depends on the company size.

Which bare metal providers can you recommend? How much control do you have over your network?

There were a lot of basic features missing. After 2 years of initial Openstack deployment there was no DNSaaS available and the loadbalancer solution was very unstable. This was partly caused by the organisation because nobody knew how to build a cloud system and first first few iterations of this private cloud were build like traditional bare metal infrastructure. If the investment for the private cloud had been used to adapt a public cloud provider for all non critical applications the benefit of the organisation would be greater.

There are tools like Kubernetes / Mesos that can help abstract the infrastructure layer so you can move between different providers. I have seen kubernetes federations setups between kubernetes clusters on AWS and kubernetes clusters that were hosted inhouse.

First of all it is important to understand that building/running your own cloud isn't only huge investment and high risk but also comes high cost of opportunity because every cent you spend in infrastructure you hope will be cheaper is not spend to increase the real value of your product. Not making this investment until your organisation and IT are "cloud-ready" decreases this risk. I have seen companies invest more than double the cost of a cloud provider to build their own cloud without having access to the features that a public cloud provider provides.

For me the questions come down to the proportion of resources to revenue and how "cloud-ready" you are.

I think having purchased the highest support configuration and being a big customer will always improve your support situation.

I fully understand your issue. Creating a new cluster means for me running a script that sets up a new cluster in ~15min. There is https://github.com/apprenda/kismatic which can help simplify your cluster setup if you run in a enterprise environment.

You can also take a look at https://coreos.com/tectonic where coreos provides a enterprise kubernetes distribution that supports updating a kubernetes cluster without downtime but I personally haven't tested tectonic.

There is currently a ongoing refactoring of the container communication stuff in kubernetes to remove all container engine specific code and just use the Open Container Runtime Interface. This allows any container engine to run with kubernetes as long as they implement the Open Container Runtime Interface.

Building a cluster from scratch is usually not a bad idea: You create a new cluster with the upgraded version, combine both clusters through federation and start moving pods from the old to the new cluster.

Upgrading a cluster in place will come in the future.

Hi XorNot,

did you publish your findings anywhere?

I can imagine that the probability of this happening is higher than when you run without docker. But on the other hand you have mechanisms like sharding and replications to deal with single machine/zone failure.

I have run database clusters on kubernetes in production without running into this particular problem.

The current state of container orchestrators for running databases is not optimal because one size does not fit all database types like with stateless applications. One solution for this problem are coreos operators which introduce third party resources into kubernetes that are specific to the database type and contain logic to manage this specific database type on kubernetes.

Thank you for the correction.

Awesome.

Although I wanted to use RethinkDB for new stuff I was very hesitant to introduce a probably discontinued product. Using a Linux product with Apache 2 instead makes the decision to introduce RethinkDB much easier.

Is somebody already working on a operator for kubernetes like coreos did for etcd [1]? What is your recommended kubernetes deployment for RethinkDB?

[1] https://github.com/coreos/etcd-operator

Hi rollulus,

thanks for the info. As far as I understand it you configure the state of the helm release + configured values in a file and apply it to a kube cluster. Depending on your cluster setup this is really helpful. Do you have a solution for triggering a rolling update of pods if a configmap has changed? In your examples I didn't see any configmaps.

Openshift is essentially Kubernetes + Redhat Extensions + Redhat Support

I use Gitlab CI and helm[1] for deploying. The last step of the ci process checks out the helm chart which is just another git repo and executes a helm install/upgrade CHART-NAME. Making things accessible is done through kubernetes ingress with nginx[2](which includes getting let's encrypt automatically for all external endpoints) so when I want to deploy a new staging version of the app I can do helm install app --set host=my-stage.domain.com .

There still a few gotchas like the pods won't update when a configmap was changed which is important because I keep the container configuration maps as configmaps. A crude workarround for this is [3] which triggers a configuration reload of the application running inside the container.

This solution has no licensing cost unlike Openshift(Tectonic[4] is another enterprise Kubernetes distribution which is free for 10 nodes) and the cost are based on the amount of time to set this up. But after you got into helm and more complex kubernetes deployments it should be easy.

[1] https://github.com/kubernetes/helm

[2] https://github.com/jetstack/kube-lego

[3] https://github.com/jimmidyson/configmap-reload

[4] https://coreos.com/tectonic/

2FA recovery codes are one of the few things I print out just because of the implication when the backup failed like in your case.

You can try rkt[1] instead. Its from a container framework from coreos which makes a lot of things easier than docker.

Running it in a simple production setup is simply writing a systemd/initd job which starts the container. No container management daemon or orchestration framework involved.

[1] https://github.com/coreos/rkt

I like the solution from Microsoft for this problem in their new Munich building: They have seperatr spaces for intense work without any distraction, areas like the most common open offices and areas for group work and meetings. Each area is its own floor and your are free to move between the areas.

Being able to call somebody and do screensharing helps a lot in this aspect. It isn't the same as sitting together in front of the same computer but way better than solving technical or conceptual issues through text messages.

Thanks!

Thats exactly was I was looking for.

I really like this idea but it doesnt work with the touchbar.

I'm running kube in production with relative small challanges. The most of my problems can from the private openstack installation kubernetes was running on.

Do you have more information on the setup of kubernetes you are thinking of? Maybe you can get some feedback for it.

After running my own k8s solution I discovered [1]. Kismatic makes a lot of the tasks to setup a cluster much easier.

[1] https://github.com/apprenda/kismatic

Deis is standard kubernetes + deis addons like their workflow.

In Germany those decision violate the first article of its Constitution: Human dignity is inviolable

I think those decisions are necessary are driverless cars but will start a huge discussion about the ethic behind calculation the minimum victim. This includes making decision if saving a child is more importing than saving a elderly.