Interop 2018 - Understanding Kubernetes - Brian Gracely

Editor's Notes

• #8: Now that we have a sense of the market size and trajectory, let’s look at some of the things that have been shaping this market for the last 5-6 years. 2009-2011: This market began with a number of offerings, both public cloud and open-source based. They were limited in functionality and often limited in the size of the open communities that supported them. 2014: Several big (new) trends emerged, especially in the open source communities. Docker spun out of dotCloud and established a new way to look at containers. Mesos and Kubernetes emerged as scalable container orchestration/scheduling systems. They both came out of existing webscale environments (e.g. Twitter, Google - respectively), and this lead alot of existing platforms to reconsider their technology architecture and strategy. 2016-2017: Where we are today is a very vibrant ecosystem of platform choices, both as open source communities, commercial software offerings and public cloud services.
• #11: Now that we have a sense of the market size and trajectory, let’s look at some of the things that have been shaping this market for the last 5-6 years. 2009-2011: This market began with a number of offerings, both public cloud and open-source based. They were limited in functionality and often limited in the size of the open communities that supported them. 2014: Several big (new) trends emerged, especially in the open source communities. Docker spun out of dotCloud and established a new way to look at containers. Mesos and Kubernetes emerged as scalable container orchestration/scheduling systems. They both came out of existing webscale environments (e.g. Twitter, Google - respectively), and this lead alot of existing platforms to reconsider their technology architecture and strategy. 2016-2017: Where we are today is a very vibrant ecosystem of platform choices, both as open source communities, commercial software offerings and public cloud services.
• #17: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
• #20: A pod (as in a pod of whales or pea pod) is a group of one or more containers, with shared storage/network, and a specification for how to run the containers. A pod’s contents are always co-located and co-scheduled, and run in a shared context. A pod models an application-specific “logical host” - it contains one or more application containers which are relatively tightly coupled. In a pre-container world, they would have executed on the same physical or virtual machine. Containers within a pod share an IP address and port space, and can find each other via localhost Applications within a pod also have access to shared volumes, which are defined as part of a pod and are made available to be mounted into each application’s filesystem.
• #21: A service is a grouping of pods that are running on the cluster based on a set of labels (selector). Services provide important features that are standardized across the cluster: internal load-balancing, service discovery between applications, and features to support zero-downtime application deployments. Backing pods can be added to or removed from a service arbitrarily while the service remains consistently available, enabling anything that depends on the service to refer to it at a consistent address. Services are assigned an IP address and port pair that, when accessed, proxy to an appropriate backing pod.
• #23: A router uses the service selector to find the service and the endpoints backing the service. When both router and service provide load balancing, OpenShift Container Platform uses the router load balancing. A router detects relevant changes in the IP addresses of its services and adapts its configuration accordingly A built-in router comes with OpenShift however it can be replaced by external load-balancers like F5
• #26: Administrators define a pool of Persistent Volumes (PV) which are backed by network storage solutions like NFS, iSCSO, AWS EBS, etc and make them globally available in the OpenShift cluster. Users within their projects can create a Persistent Volume Claim (PVC) in order to request a PV to be available within their pods. In the pod definition, a developer can refer to the PVC and mount the requested persistent volume inside the pod at an arbitrary path. If a pod gets restarted, OpenShift mounts the same persistent volume into the pod again so that the pod data is available. PVs outlive the containers that were using them.
• #27: Dynamic provisioning allows provisioning persistent volumes on-demand when users request it rather than admins predefining them in advance StorageClass is a blueprint of how to provision persistent volumes on a network storage. OpenShift provides a set of provisioners that determine what volume plugins should be used for provisioning the volumes. OpenShift also supports third-party plugins that are not part of Kubernetes, such as NetApp Trident Admins creates a catalog of StorageClasses available in the OpenShift cluster. StorageClass names are arbitrary names to communicate their characteristics Users can create a Persistent Volume Claim and specify the name of a StorageClass to instruct OpenShift on the type of persistent volume that should be provisioned for the them