Fabio rapposelli pks-vmug

Editor's Notes

• #5: Walk Thru of a Container 101 Describe benefits of containers and establish common understanding for K8s discussion.
• #6: With announcements today about PKS lets look a little at how K8S is different from PCF From the Developer point of view: I check my code in just like if I were pushing to PCF But in addition to application artifacts, the pipeline is going to build an image for me … In this visual we have a K8S cluster already running docker as the backend container engine, so our CI/CD pipeline will build a docker image for us and post it to a registry, in this case VMware Harbor Afterwhich, the pipeline will instantiate a K8S deployment to run our docker image based application as a set of pods in a replica set in case a worker note goes offline. The developer can than create a ‘service’ that gives worker nodes (or any external node) running the kube-proxy service the ability to route to where those pods are and access the apps/microservices running in them. Ingress routing from external is similar to that of CF with an external DNS map being required to forward requests to 1 or more worker nodes running kube-proxy One of the key differences is that Kubernetes isn’t opinionated on how the container image should be built, this give more flex to the developers but in some cases can make things more difficult for operators as we’ll see later on in the presentation Agility is why developers want it 
• #7: Lets walk thru what makes PCF so Powerful …. From the Developer point of view: I write my code {} I check it into a repository A CI/CD pipeline then builds & tests my code, then outputs an ‘artifact’. In this visual, we will use a java app, so it’s a war. The pipeline then ‘pushes’ the artifact to PCF to stage From here its all up to the platform …. Staging occurs, where an image called a ‘droplet’ is built by combining a (1) a read only root filesystem , (2) a buildpack that is a tarball that contains the exec components like tc server for example to run a java app, (3) and the app artifact After staging, the app can now be run. For example if we say that we want 2 instances of the application, PCF will launch 2 containers using the same droplet image we just compiled and schedule them across CF Availability Zones. This gives us the ability to keep our app up if an AZ were to go offline. PCF also creates a route map for our application so when a request is forwarded to it, the request can be routed to the correct containers. PCF calls these containers Application Instances or AIs Developers also benefit from a rich set of buildpacks in the platform support many application dev frameworks. Even .net apps with Windows Container hosts are supported by PCF. Agility is why developers want it 
• #9: Application Purchases Will Increasingly Be "Build," Not "Buy" Gartner predicts that by 2020, 75 percent of application purchases supporting digital business will be "build," not "buy." Gartner's research shows that many organizations already favor a new kind of "build" that does not include out-of-the-box solutions, but instead is a combination of application components that are differentiated, innovative and not standard software or software with professional services (for customization and integration requirements), or solutions that are increasingly sourced from startups, disrupters or specialized local providers.  http://www.gartner.com/newsroom/id/3119717
• #10: Adopting Agile processes is a key driver to help a business digitally transform. Software truly is eating the world. The key for these business is changing not only the way apps are coded, for example cloud native/12 factor) but also the processes by which they are built and operationalized Speed: Compose apps as micro services to allow more scalable and rapid development. Work for smaller releases to reduce sprints Automation: Automate everything. It reduces risk and increases speed Quality: Test Driven coding, tests should be part of the pipeline, if a fault is found, tests go back into the pipeline. Agility: Release often, design apps and pipelines to allow for frequent pushes.
• #11: By making the first task on any software effort “delivery” - deploy the code somewhere, even if it doesn’t do anything. And then keep doing that every time you change anything…
• #19: In the ‘New Stack” required for an agile world , the Developer and the Operator need to act as 1, or at least a 1 pizza team (or 2 pizza if they are hungry). Sort of like the acronym Devops  This means that just like the Developer needs everything API Driven & self service from the platform, the Platform Operator also needs everything API driven & self service from his infrastructure. The Devops team cant lob stuff over the fence, they own it!!!!
• #29: API server: Target for all operations to the data model. External API clients like the K8s CLI client, the dashboard Web-Service, as well as all external and internal components interact with the API server by ’watching’ and ‘setting’ resources Scheduler: Monitors Container (Pod) resources on the API Server, and assigns Worker Nodes to run the Pods based on filters Controller Manager: Embeds the core control loops shipped with Kubernetes. In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state Etcd: Is used as the distributed key-value store of Kubernetes Watching: In etcd and Kubernetes everything is centered around ‘watching’ resources. Every resource can be watched in K8s on etcd through the API Server Kubelet: The Kubelet agent on the Nodes is watching for ‘PodSpecs’ to determine what it is supposed to run Kubelet: Instructs Container runtimes to run containers through the container runtime API interface Docker: Is the most used container runtime in K8s. However K8s is ‘runtime agnostic’, and the goal is to support any runtime through a standard interface (CRI-O) Rkt: Besides Docker, Rkt by CoreOS is the most visible alternative, and CoreOS drives a lot of standards like CNI and CRI-O Kube-Proxy: Is a daemon watching the K8s ‘services’ on the API Server and implements east/west load-balancing on the nodes using NAT in IPTables
• #30: POD: A pod (as in a pod of whales or pea pod) is a group of one or more containers Networking: Containers within a pod share an IP address and port space, and can find each other via localhost. They can also communicate with each other using standard inter-process communications like SystemV semaphores or POSIX shared memory Pause Container: A service container named ‘pause’ is created by Kubelet. Its sole purpose is to own the network stack (linux network namespace) and build the ‘low level network plumbing’ External Connectivity: Only the pause container is started with an IP interface Storage: Containers in a Pod also share the same data volumes Motivation: Pods are a model of the pattern of multiple cooperating processes which form a cohesive unit of service
• #39: (click) Configure a vSphere Cloud Provider Manifest. Provide key info …. like vCenter Creds & default datastores (click) Restart all core K8s components & add new flags to enable vSphere Cloud Provider (API, K8s Ctrlr, & Kubelets (click) Create a K8s Persistent volume kubectl cmd applys the yaml via the K8s API… The Kubelet picks up the work and uses the configured Storage provider The Persistent Volume is created on the Datastore (can even optionally pass vSAN Storage Classes for SBPM) (click) The vmdk is represented as a K8 PersistentVolume A running POD can now make a PersistentVolumeClaim and mount the volume https://vmware.github.io/vsphere-storage-for-kubernetes
• #42: A PCF deployment will emit various logs & metrics from various sources.
• #47: How do we modernize IT and Applications across multiple clouds and multiple platforms: 1. Make the cloud easy: Create /Deploy/ OOTB content / integrations for a private cloud A.) Easy deploy(LCM) B.) Quick TTV(OOTB dashboard, sizing, workflows, Integrations) infoblox, snow, puppet, teraform, OOTB content C.) SaaS services 2. Simplify dev consumption: Unified consumption model across all clouds A.) Globally consistent IaaS (API) B.) Blueprints and Iterative dev C.) Integrated catalog of services and pipeline 3. Consistent, unified ops: Unified Ops for all apps across platforms A.) Closed loop workload scheduling (Automatically place and re-balance VMs) B.) Realtime full-stack troubleshooting and monitoring (wavefront) (extra slide) C.) App intelligence (bringing together infra and apps, NI, apps, infra metrics) (possible extra slide)
• #50: MG: Add Opsman experience here