At the time of the talk I was reading up on the many resources available on internet about how best and where to get started with Kubernetes. This talk unravelled a vital aspect about Kubernetes and the whole containerization world of web application. Jan kicked off the session by asking – by a show of hands, anyone who had experimented with Kubernetes or Docker – of course my hand shot up on the Docker part.

Immediately, I became interested in the next question he posed to the gathering. Why Containers? You are probably already guessing how many hands had been paraded on the Kubernetes experimentation – just a few!! For someone in the state of mind like I was at the time – this set home. He told about a Pet and Cattle analogy – many cattle lovers won’t love this one however he simply meant to say that if your pet for any reason dies, you might want to make a special commemoration to the funeral than a farmer with thousands of cattle who won’t care if one cattle dies. If we are to apply this to containerization of application, we will observe a surge of management control and consistency across your development line and as if that is not enough your continuous delivery trail will bolster development and productivity while keeping costs low.

Nevertheless, achieving the core benefits of containers – in this case Kubernetes he recapped of the three unsophisticated rules. First and foremost, stick to stateless – keeping our application to no persistent storage like it was intended. Additionally, running a single process instance on a node and finally, he warned strongly against running an application as a root. This is critical when designing a secure system. Whether malicious or because of bugs, a process may have unexpected consequences at runtime. One of the best ways to protect yourself against any unexpected access is to grant only the minimum amount of privileges necessary to a process to run. All having been said, he added that very few developers stick to these rules for a simple reason of trying to force result, or to put it plainly - to fix a square block in a round hole!! However, thinking about it – what are some of the aspects that Kubernetes will NOT do for you(us). The system will not limit the types of applications supported, nor will it deploy the source code and of course it won’t build your application!! Furthermore, Kubernetes will NOT dictate logging, monitoring or alert you of any errors, nor provide application level services and it won’t configure a language or system. These are all responsibilities a developer will devise ways to include in the whole setup.

Digging a little deeper, given the different kinds of containers they all seem to have the same setup. In this next section I will deliberate on a few terms explained in the session to remember about Kubernetes. A pod, being a group of one or more containers (could be Docker containers) with a shared storage or network. This is the smallest and simplest unit in the Kubernetes object model. Pods provide a self-healing capability at cluster scope – readiness nature that waits for redundancy to give traffic whereas the liveliness nature that will restarts a pod. Kubernetes pods are mortal, while their IP addresses cannot be relied upon to be stable overtime and this creates a problem where a service or Services determine a policy by which to access pods. This bring us to an Ingress; this is simply an object that manages external access to services in a cluster. It can provide load balancing or load distribution of the traffic. Controllers maintain a stable set of pods running at a given time and are classified in three different modes namely; - Deployment, Daemon and Replication. A common mistake a developer does while deploying is to tag their versions with ‘latest’, as developers this in a total no DO! Additional deployment tips are as follows – simple minimal configurations will make errors less likely, furthermore we were advised to declare unique values with in a deployment process as well as staying away from naked pods simply because they will not be rescheduled in the event of a node failure. The best way to separate a set of pods is to namespace them. Kubernetes starts with two initial namespaces namely, default and kube-system. Why namespaces? Probably you are already guessing but this provides us (you) with the ability to create a role-based access (RBAC) security. It’s a is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise.

Finally, Jan suggested Google for Kubernetes given the amount of time setting up a Kubernetes cluster. He exaggerated how quick and simple it is – indicating only 5 clicks to have one already setup.