Table of Contents
A thanks and shoutout to Cloudibility for allowing me to talk about Rook together with Kim-Norman Sahm. Checkout their Twitter: Cloudibility UG.
The speaker party was filled with cool people and a nice atmosphere at StrandPauli.
Obvious visit to the Hamburg Reeperbahn. Just kidding, we just used the train station to get back to our hotel (as far as I remember) ;)
Let’s see what awesomeness the day will bring. I hope I’ll learn new stuff about containers and Kubernetes, and hopefully meet all the cool people again. :)
“Back to the harbor.”
..where containers originate.
Globalization in the port. How containers changed the world of harbour work. - Ursula Richenberger, German Port Museum
A container combines two important points. Storage and Transport. Characteristics of shipping containers are:
- “Toilets, Store” - Container are not for goods transportation only.
- Transport by:
These can be seen as the following in the IT world:
- Ease of use (e.g. YAML manifests)
Such hubs in a harbor are the core which made the Hamburg harbor especially powerful in global trading.
A huge revolution happened in the transport logistics because of containers. Because of the transport container revolution, many things have been automated though still not everything.
“In the reality a container transports goods, but aren’t our applications in containers also just goods? Goods that we want to deliver fast to our customers.”
Emergence of Linux Application Containers and the Rise of Kubernetes - Craig McLuckie, Heptio
“dotCloud” has renamed themselves to “Docker”. They had the problem of wanting to run “user” code in production and be fast with it, instead of “having to review every bit of code”.
Google uses cgroups to use resources more efficient. Though at first the code was private, but they donated the cgroups code. This has advantages for everyone and especially for Goole, because it reduces the workload of “rebasing” on upstream changes happening.
They open sourced their code for it and with that the Linux kernel built namespaces. cgroups, namespace and other parts came together, not only for good of the community but also for Google, as already mentioned.
“upstream is powerful” - Craig McLuckie
The more you push your changes to upstream, the less work you have to do to maintain your implemented “feature set” (e.g. no rebasing all the time).
Google with their experience, looking at you Kubernetes, gave us a “blueprint” in regard of that it is possible to run at scale with containers as they do.
The thesis behind Kubernetes is/was that we can give it the community, but simply offer it “as a Service” running it better than “anyone else”. This thinking allows Google to score big time, because “every” company runs it, also lowering (new) developer time to production (how long a new developer needs to get changes to production).
Kubernetes project brought a lot of companies together, in discussions for features and issues helping out by contributing and/or sponsoring such projects.
The Cloud Native Evolution - Ihor Dvoretskyi, CNCF
A monolith application can be seen as a static glacier, which is hard to fix bugs in and further develop.
Destroying an application is a benefit as long as you can redeploy it, looking at containers you normally just “throw away” used containers.
Kubernetes is the first project to graduate from all of the Cloud Native Computing Foundation projects.
*Rook is seen on a slide during a conference photo*
The CNCF projects can live next to eacht other and are not in direct competition. CNCF landscape can be viewed in it’s full extent here: CNCF Cloud Native Interactive Landscape.
The most important is the community. Not only are there more than 23 thousand contributors contributing to CNCF projects, but also a huge meetup community all around the globe. To further help with the community, there are also many initiatives (e.g. meet the maintainers).
Distributed Database DevOps Dilemmas? Kubernetes to the rescue! - Akmal Chaudhri, GridGain Systems
“Don’t buy these books.” - Akmal Chaudhri
He also writes articles from time to time. A list of his articles can be found here: DZone Akmal Chaudhri Articles list.
Apache Ignite is a In-Memory Computing Platform.
Peer to Peer system. It allows for pessimistic and optimistic transactions.
Because of the in-memory caching, you can run SQL queries, machine learning and other tasks on the incoming data across the cluster quickly (e.g. IoT data).
Running Ignite inside of Kubernetes, allows to you use the Kubernetes scaling features combined with service discovery.
It allows you to scale ‘as needed’ by utilizing
kubectl scale command.
The “what” and “why” of Flatcar Linux, a friendly fork of Container Linux - Chris Kühl, Kinvolk
They have an upcoming event about the “stack” below the applications and/or container runtime on September 28-30, 2018 in Berlin, Germany.
They deliver Flatcar Linux in three channels as Container Linux:
You should always run some nodes with the beta version to test that changes are compatible with upcoming
Two the points why they forked CoreOS/Container Linux are:
- CoreOS was bought by RedHat.
- Though they already talked about it before that. They generally try not to make it in a competitive manner.
- No support for CoreOS/Container Linux available (only when using the full Tectonic stack).
Kinvolk already exists for three years, so they seem to be successful with their “goal”.
Their goal is to be an independent infrastructure company for cloud native technology.
Flatcar Linux has support for Typhoon.
For now they are only offering support for larger installations of Flatcar Linux and contribute more to maintenance of Container Linux from which Flatcar Linux benefits from. Another goal for the future is to offer commercial support for Typhoon.
As last year, I only ate the burger, because it was and is good. Only thing all of us noticed, it is a bit hard to scale burger cooking unless you add more Big Ben Burger trucks.
HandsOn PodSecurityPolicies - Erkan Yanar
PodSecurityPolicies are to further cage in applications running inside containers.
On OpenShift it is by default required to run containers as non root.
PodSecurityPolicies you just need to change the admission controller flag on the API server(s).
Pods are restricted by
ReplicaSets, because they only “spawn” Pod objects.
- Authentication: know who you are
- Authorization what you are allowed to do.
allowPrivilegeEscalationdisallows more privileges and/or capabilities to be “given” to containers.
emptyDircan possibly be used to DoS the filesystem of the host system.
- At least looking at storage space limitation one could use
Quotasfor storage requests.
- At least looking at storage space limitation one could use
hostPathis also evil if used to for example modified
/etc/shadowand/or other important files.
readOnlyRootFilesystemallows the container filesystem to be read-only to prevent applications from filling your host disk through that and/or “attackers” to write files.
Migrating the Next Generation Mobile Core Towards 5G with Kubernetes - Karla Saur, Intel
They implemented features such as “core pinning” to further keep workload from swichting between CPU cores.
During their performance tests they found that Kubernetes does perform a little less well than when the application is not run in containers. Though those were just about 5% and was okay for them, because they have simplicity for scaling through that.
They wrote their own load balancer as existing load balancer are more or less “just” focused on level 4 and 7.
The NGIC gateway is available under project:ngic | gerrit.opencord Code Review.
Another project they have open source is MULTUS CNI plugin. This CNI (plugin) allows you to attach multiple network interfaces (CNI plugins) to one Pod.
Distributed storage with Rook - Kim-Norman Sahm, Cloudibility & Alexander Trost, Rook Contributor
A great presentation about @rook_io, the sandboxed project of @CloudNativeFdn at @ConDaysEU #CDS18 pic.twitter.com/tYQy3vY47A— Ihor Dvoretskyi (@idvoretskyi) June 20, 2018
It was an amazing experience talking about Rook. Sadly not all parts of the demo worked, “Damn Demo gods have left us”.
I can reassure that it works, after the talk and questions I checked again and the Elasticsearch cluster demo part had started up fine. Additionally I deployed the “same” manifests again in the evening (only change was to add HTTP basic auth to the Ingress) and the Elasticsearch cluster started fine again.
The demo files can be found here: GitHub galexrt/presentation-distributed-storage-with-rook.
The slides can be downloaded as a PDF here: Distributed storage with Rook.pdf.
Today it was Pulled Turkey Burger time, it was also great. Though as mentioned yesterday there was a good amount of wait until you have gotten your burger.
As last year it was awesome meeting all those people and learning new stuff about containers through the variety of talks. This year was especially cool for me, because it was my first time speaking at a public conference.
P.S.: Please let me know (by comment or email), if there is anything I can improve to make this post about the conference even better. Thanks for reading!