Getting Started with Containers and Google Kubernetes Engine (Cloud Next '18)

[Music] hello Google cloud next how's it been doing good all right lunch session everyone's eaten Wally talk this is good brown bag lunch all right so welcome to getting started with containers and google kubernetes engine we have 50 minutes to give as many details as we can about gke to make you all experts before we begin quick show of hands how many people have ever deployed an app to kubernetes before not that many that's exactly what this session is all about then so my name real quick intro my name is Weston Hutchins I'm a product

manager on gke and I'm Anthony Bhushan a customer engineer specialist focusing on app dev and kubernetes so everyone said they hadn't deployed we're gonna go straight through demo no slides show you how easy it is to get started take it away Anthony all right thanks Wes so today we're gonna demonstrate again how easy it is to get a few containers up and running on google kubernetes engines so let's just dive right into it what you're looking at here is a Google Cloud console that is highlighting a kubernetes engine cluster I've already created this if you

haven't created a kubernetes engine cluster before it just takes a few clicks or a simple g-cloud command or even a simple terraform resource it's actually quite simple um but since we already have this let's actually how do we use this cluster so I'm gonna click on this connect button and I'll actually get an auto-generated g-cloud command to fetch credentials to be able to interact with this cluster and via coop control so G cloud is our SDK so you'll see here that I have a GK cluster but that's not the one we want to use we

want to use this one so this great so now let's test that we've actually connected to our kubernetes cluster by getting the nodes that comprise our cluster and there we go so as you can see here are the three nodes that comprise the cluster that I showed you earlier at the end of the day these are just virtual machines right what's different is that kubernetes allows us to interact with these VMs in a better cleaner way so we're not going to SSH into these nodes we're not going to write imperative instructions to actually install our

application instead once our app is built in containers all we have to do is write some declarative kubernetes manifests and these containers that comprise our application will be scheduled by communities somewhere on these three nodes right so the application we'll be working with today is comprised of an angular UI a goaling API and a Postgres database and two containers they allow us to package and isolate these components independently it really enables a concept of micro services and so within that design each of these components has their own code and their own docker file which specifies

how to build the image into a container and so as I mentioned once these containers are built all we need are kubernetes manifests to implement our desired state in the cluster so let's actually look at what that looks like so in the CMO file is our kubernetes manifest and this is for the UI aspect of our application so what you'll see here is that we're telling kubernetes that we want a load balancer to actually front a what is called a kubernetes pod that is based on this template now a kubernetes pod is a grouping of

1 or n containers so in this case our UI pod is going to run our UI and our API containers and we want to replicas of that pod cool the magic of kubernetes is that once we provide this desired state criminals will a implement it and be take action at all times to reconcile the observed state with the desired state that we have here so let's get this application up and running we have to build a container image we have to apply the manifest to kubernetes and we're going to use scaffold which is a tool

that was built an open source by the amazing container tools T team here at Google we're going to do all of it with a single command let's look at that and that command is scaffold dev great so we'll see that all the steps that I'd mentioned are now being kicked off by this tool well dive into the details of scaffold a little bit later in the talk but while it's doing its thing West I wanted to ask you how familiar are you with our GCP logos not not really at all okay well it's a good

thing then that our demo application is actually a quiz so we have a pop quiz for you to see if you can match the product or use case with it's appropriate GCP hexagons so now we see that this application is actually deployed we're gonna have to before we get into the app let's look at the kubernetes resources that were created so I think before we mentioned that we want pods so let's look at those great so we have two replicas of the UI pod and then one replica of the Database pod I didn't show that

manifest but that was also recursively applied as it was in the kubernetes manifest folder we also will be able to look at the load balancers so right now gke in the back end is actually provisioning a network load balancer to front ru ipods and so you'll see that it's actually also provisioning an external IP address again this is really the magic of cribben at ease all we have to do is write these declarative files and we get our desired state so let's look at that again and we'll see that we now have an external IP

address to access our application so let's throw that into our browser and wes this is made just for you so you're on the spot now I hope you didn't practice this at all and I failed Management Service I I'm gonna go with one on the left's for that one hey I don't know you shared something alright that's correct let's run it again in cloud tools for Android studio I don't think it's either of those but probably the one on the left as well okay so this is a placeholder for once I actually don't have a

hexagon okay all right one more time let's do one more as it's run a different one this one also does not have a there you go it's a debugger debugger is gonna be the one all right awesome hey how about a round of applause for Wes I passed yeah thank you quite a bit so it's clear that Wes and those GCP but what's also clear is that it can be really easy to get up and running with containers and kubernetes engine so let's quickly recap what this demo did we had a gke cluster again this

is really easy to create with a single click we've connected to this cluster we built our applications in containers we've declaratively deployed them to kubernetes and we've exposed those containers behind a load balancer so that we could all go through the demo today and so and Wes again ace the GCP quiz so we did this all with scaffold and google kubernetes engine in just a few commands and so today we'll show you how to get started really easily with a lot of the things that you'll need to do to be able to have a demo

like this so back to you Wes cool thank you so I know that was a quick you probably had us all a lot of things on-screen that you didn't quite understand we're gonna go into a bunch of the the mo file definitions and kind of how we build this out and a little bit later can we jump back to the slides cool all right so a brief history of containers and kubernetes soup containers have been around for a long time they've been a part of Linux for for quite quite a while we really started to

see container adoption pick up with the introduction of docker in about 2013 and that was a key moment where public adoption of containers really started to take off docker offered a lightweight container runtime and an amazing packaging and deployment model where you could bundle your app and all its dependencies and deploy that consistently across different environments now when docker came out they were really focused on that dev workflow and solving the packaging and deployment for a single node across the single container as well and we all realized that it wasn't the full solution the eventual

goal would be to manage that manage multiple containers across many different nodes and that's when kubernetes really started to the seeds of kubernetes start planted at Google was around 2013 timeframe so kubernetes really at its heart is an orchestration tool now what does that mean it really means that you can package and deploy multiple containers across multiple hosts and kubernetes takes care of most of the heavy lifting for you with things like scheduling an application health checking and more of those types of it or more of those types of things but in my opinion kubernetes

is really two powerful concepts the first is that it's an abstraction over infrastructure and this is really really important for your developers we wanted to make it so that most developers didn't really have to retrain their skills depending on whatever cloud they were using or if they wanted to move from something on Prem over to a cloud platform as well kubernetes gives you that consistent base layer that allows the operators to worry about infrastructure and the developers to get a consistent tooling platform and the second real powerful tool of kubernetes is that it's a declarative

API everything in kubernetes is driven off this model of declare your state declare what you want to have happen and then kubernetes has built-in feedback loops that will make that state reality and they're constantly observing we can write even custom controllers to handle a bunch of different state reconciliations for even new objects that you want to create and the best part about kubernetes is that it tries to encapsulate a bunch of best practices around application deployment and and scheduling so things like where does a particular container need to get scheduled on which node is that

node healthy can I do can I restart that node if it goes down how do I provision storage we have storage providers for a number of different platforms built into kubernetes through the through the ecosystem logging and monitoring is also integrated and we've seen a lot of extensibility with tools like Prometheus and Garr fauna that work on top of the kubernetes system and even going so far as things like identity and authorization there's a ton of work that happens in the community every month on adding new and new features to the platform it's it's actually

quite astounding how fast Nettie's iterates and it's really important to always make sure you're keeping up with the latest developments but with great power comes great responsibility i'm kubernetes can be a bit overwhelming there's a lot of power under the hood here and there is inherent complexity with the system as powerful as kubernetes and when we talk to users we typically you know break people up into two camps one is people that are operating the cluster cluster operators and the second one is application developers and from a cluster operator perspective installing kubernetes is relatively straightforward

the real pain comes when you have to manage the day to operations this is things like setting up security and TLS between my nodes encrypting at CD and making sure that no one can access it doing disaster recovery like backup and restore and even things like node lifecycle management if a node goes down these are all things that cluster operators don't always like to handle themselves and we see a lot of questions and forum posts on how to operate kubernetes at scale one of the key missions of gke when it first came out was to

take the heavy lifting off of the cluster operators and give it to Google and that's really the big power of google kubernetes engine is that we wanted to offer this fully managed solution where Google runs your clusters and you as the developers get to focus on the applications so gke is our hosted cloud managed kubernetes solution we were GA in August of 2015 so we've been running a number of production clusters for three years now one of the nice things about gke is that we take upstream kubernetes and we ought we try to keep as

close to upstream as possible and are always releasing new versions of gke as new versions of kubernetes are coming out but we wanted to add deep integration with GCP so we make it really easy to use other features like logging and monitoring and identity right out of the box with kubernetes and gke so let's look at the architecture of how gke is deployed on top of GCP so there's typically two parts to kubernetes two major parts to kubernetes we have the control plane and then we have the nodes that make up your cluster and on

gke the control plane is a fully managed control plane controlled by Google we run this in our own project and we have a team of site reliability engineers that are constantly doing things that I described on the day to operations they're scaling the clusters their health checking it they're backing it up they're making sure that Etsy D is always upgraded with the latest and greatest security patches this is really the operational burden taken off of the end user and put into the hands of the Google engineers there are two ways to spin up the control

plane for gke we have the classic way which is zonal where we spin up a single node and just recently you announced general availability of regional clusters which allows you to spin up a multi master high availability control plan which I'll cover in a couple of the later slides now the second piece are the nodes and these run in your project these are where you're actually going to deploy your containers and we call these the workers of the kubernetes cluster now on gke we have a concept of node pools which is a group of homogeneous

machines with the same configuration I'll talk about that on the next slide for these nodes we are the only cloud platform to offer a fully managed node experience and what that means is that we provide the base image we constantly keep it updated and we have features like no doubt or repair and node auto upgrade that allow you your cluster to keep revving with the latest and greatest upgrades without having you to do anything at all so node pools are also a gk concept and this is there's a lot of advantages to building out things

with node pools so node pools are really just a group of related machines it's the same configuration if I could have an n1 standard run instance I can create a node pool of size three and that will give me three in one standard run instances now what's neat about node pools is that it makes it really easy to mix and match different instance types so you can spin up note pool a with the standard configuration then you can add a second node pool with things like preemptable VMs or GPUs so that you can target specific

workloads to those node pools even better node pools make it really really easy to add availability to your application so if I'm running in a Engels own let's say us central 1b and I want to add a failover to u.s. central 1a all you have to do is create a new node pool in that new zone and then attach it back to the cluster and this is just a really nice way to group related instances together and then scale out your application so let's actually walk through what happens when you upgrade a node one of

the features that we offer to GK customers is this feature called maintance windows now maintenance windows give it's basically you telling us a four-hour window when we are allowed to upgrade your notes so if you have high traffic during the day and you want to make sure that upgrades happen at midnight or whatever you can specify this window we will only upgrade to your master or your notes during that timeframe so what happens is we will go and drain a node and what this does is it removes traffic from that node and then we do

an operation in communities called cordon which makes it so that new pods don't get scheduled to that node at this point we spent up a new VM on the latest version of kubernetes and then we attached it back to your cluster so we do this one by one in a rolling upgrade fashion there is a couple other ways to upgrade that I'm going to cover in a little bit later but that's generally how most of our users keep their notes healthy and up-to-date the other feature that we offer for node management is node auto repair

and no two auto repair is basically a health checking service there's a lot of reasons why nodes can go down whether it's kernel panics or disk disk errors out of memory errors etc node out of repair is constantly monitoring the health of your cluster for particular errors and if the health check fails like it does here and it goes into a not ready state it will go and do the same operation that we did during upgrade where we'll drain the node we'll spin up a new one and then we'll reattach it back to the cluster

this makes it really easy to make sure that your your nodes are always healthy and at the set amount that you want in your cluster and as I said all of this is really the end journey to get you to focus on the things that matter which is your actual application development and let Google do the heavy lifting for kubernetes cool with that I'm going to hand it back to Anthony who's going to go into much more depth on the building deploy lifecycle awesome thanks Wes so 18 minutes into the session and we finally have

reached the title of our talk so we're going to talk about getting started with containers in kubernetes engine and these are the key concepts that we'll be discussing today all focused again around the second narrative of actually using and deploying things to kubernetes so let's start with building and deploying containers so when it comes to this space there are two key areas we want to consider one is enabling developers and two is automating deployment pipelines into environments like staging or production and both are important but let's start with the developers so for developers who are

new to technologies like containers and kubernetes this is often what the workflow feels like initially there's a lot of unknowns the magic in the middle could be docker run cube CTL apply bash grips make files a whole bunch of different approaches and this can be a bad time for developers right what you end up with is a bunch of differing workflows with long feedback loops between code change and actually being able to interact with their application running in its runtime environment right and so there's you know overhead of maintaining this workflow there's no consistency across

what should be a standard set of steps this means that each developer has their own method of running locally and and this makes reusing and replicating things in the development lifecycle really hard and so if portability is one of the key tenets of kubernetes and containers and this is a problem that needs to be solved and so that's where scaffold comes into play so if you remember scaffold was the command that we ran a scaffold was a tool that we used to get our quiz application up and running on gke the scaffold is perfect for

standardizing and enabling iterative development with containers and kubernetes so with scaffold all developers have to do is focus on step one working with their code scaffold takes care of the rest of the steps in the middle and will not only give that end point back to the developer will actually stream out logs to the developer to be able to allow them to debug or make Changez so let's actually switch back into the demo and revisit our quiz application so here I am with back in the terminal and what we see here is that scaffold dev

this is a command that will actually continue to run once our application has been deployed and you'll see here that it's actually streaming back logs from my application now it's pretty cool is that what it's also doing is watching for changes so if I actually want to change that quiz application we're not having to re kind of you know go through the process of building our containers and and then applying those kubernetes manifests all we have to do is focus on the code so let's actually go into the application okay so we'll see here we're

back at our application directory so I'm actually going to go into the index.html file I'm gonna make some serious changes and there's nothing more nerve-wracking than using vim in front of 500 engineers but what I'm gonna do is let's say that you'll see here I initially wanted to quiz Wes but maybe I want to quiz everyone in the audience so what we're gonna do here is change this and say hello io 124 attendees oh oh spelling is hard all right cool all right so we're going to change that file and great I've changed my code

and notice what I haven't done I haven't gone into any docker file I haven't gone into coop control but what I have is this scaffold dev process that's continuously watching for changes in my code and now we've already completed our deploy and build process within 12 seconds and so our application is now up and running again and so if we revisit it we see that our code has actually changed behind that same endpoint has anyone brave enough to take this one it's it's the one on the left I'll just also pulse pair oh my goodness

it's the one on the right ok well that that was not playing ok great so let's actually cut back to the slides so scaffold that's sorry so scaffold is actually a pluggable architecture so one thing to note about that is that while you saw me deploy into a kubernetes engine cluster those running in the cloud we can actually use scaffold with kubernetes environments that are running locally in our laptop so that's things like mini coop this would result in a much faster deployment kind of process but it all depends on the culture of your kind

of development teams and if you're doing remote development or local development what we can also do is not only use our local docker daemons so to build these docker containers I actually was using docker on my laptop but what you can do is actually begin to outsource and push some of that heavy lifting save our battery with tools like Google cloud build which is our managed build service right so scaffold is a really useful tool that makes for very happy and productive developers right scaffold can also work well for our automated deployment pipelines but we'll

get into that first we want to dive into a few tips so throughout the session we'll just be sprinkling in if you are just getting started what are some things that you have to keep in mind and so our first tips are around actually building containers we have a tip on performance and a tip on security so first around performance make sure that you slim down your container images so if you're coming from the land of running everything in virtual machines it can be tempting to stuff everything that we want into into containers and treat

them kind of like VMs that also makes for a bad time because it makes for slower pull times and if containers if their value prop is really around increasing deployment velocity slow image pull times will only hamper teams and especially if you're working at the scale of hundreds if not thousands of containers and micro services so an approach to slim down container images is to actually use multistage builds this is basically an approach to build your binaries in one container and then copy that final binary to another container without all of the build tools SDKs

or other dependencies that were needed for the build to build that artifact once you do this then you can actually deploy things faster as we have a more lightweight container image the second tip here is scan your images for vulnerabilities so Google's hosted container registry service provides vulnerability scanning this is an alpha feature but basically what this does is that anything that you push to a docker to the container registry in Google will actually be scanned with this feature enabled and so you can also enable it to send you notifications should there be a vulnerability

via pub/sub along those same lines when getting started there are a swath of public images out there in examples public docker hub repos that are awesome for learning and awesome for just kind of experimenting with but they introduce inherent risk if we start to take some of these public containers their untrusted and unverified and actually implement them into our application sacks so avoid doing that so now that we have containers we're still you know now that we have a container workflow for our developers we're still missing how we deploy containers into production at scale in

kubernetes right so if the end goal of containers in kubernetes is to get teams to move faster then a large part of this actual magic starts happening when we have automated build and deployment pipelines across environments for staging or production now though let me let me preface this with the opinion that there's no one right way to do continuous integration and continuous delivery also known as CI CD but we can point to a few patterns with an example pipeline here so if a developer is pushing to a feature branch or maybe tagging a release we

should expect the developer's workflow to end there it should end up in a kubernetes environment with a provided end point assuming tests pass and the way that this the way that it does this should be an implementation detail and actually hidden away from the developers so in this scenario we're using cloud build again in this case cloud build has build triggers that can kick off a build with multiple steps those steps can actually include building the binaries maybe running unit tests building the container image and finally pushing that out to a registry Google cloud build

is awesome because it is able to provision and manage multiple steps either sequentially or in parallel right and so each of these steps actually is executed within a docker container and then across all of these steps we have a shared workspace that being said they're like you know there are a lot of other tools in the ecosystem that can fulfill this CI need and some of these may already be present in your existing workflows Jenkins is a popular one for example that we see so once we have this newly tagged image in our registry we

can now have that trigger a deployment pipeline for continuous delivery so cloud build jenkins these tools can also perform this functionality but in this example we're using a tool called spinnaker to perform our continuous delivery it's an open source tool from Netflix that Google is heavily invested in any CD tools should be able to have a pipeline triggered via a newly detected image and kick off additional steps to checkout kubernetes manifests maybe deploy them into different environments like staging production spinnaker here gives us additional features like execution windows maybe we only want to automate deployment

has a specific time or maybe we want to enforce manual approvals from our operations team before releasing into production there's a whole bunch of things that that spinnaker enables safe roll backs being able to have a nice UI around your actual pipeline and so it's important to again when looking at these different tools make sure that you're choosing a tool not because of the hype but because it actually fulfills the use cases that you are looking to achieve it's like I said cloud build can also do this continuous delivery and deployment phase so a couple

tips when deploying into production one very simple limit access to production you'd be surprised i've seen a handful of customers that will give coop control troops ETL access to their developers in in production and what we actually want to do is use some of GCPs and native kind of isolation primitives and so in this kind of diagram we're using a GCP project which owns I am hierarchy to actually limit access to the kubernetes cluster and running in production right so maybe we'll just give this access to cluster operators and then give this access to a

service account for our CI CD pipelines and then second tip is to keep your kubernetes configuration as code this is pretty key because we'll want to one store the existing state maybe we're template izing our kubernetes manifests and want to customize that depending on each pipeline but we also want to track a history of applied manifests and get in source control management is a great way to do that so now that we've covered building containers we have to expose them right to be able to interact with them how do we actually expose them to internal

or external users so let's actually jump back to the demo to take a look at how kubernetes networking works cool actually I'm going to close this so I'm just ending the scaffold dev process I was running earlier and I actually want that to be redeployed so this will actually not keep it in that iterative development State we're going to run and deploy that application without the kind of feedback loop but in the meantime let's actually switch our cluster so communities are actually going to use the not this cluster Thrun IDs cluster okay so kubernetes networking

regardless of gke or elsewhere requires that a single every single pod gets its own IP address so let's look at that it's kind of nice if you look at other orchestration tools these might actually require you to do port mapping or something complex within which at scale can be really difficult but you'll see here we have I've actually running I'm running the same application in a different urban IDs cluster and I have three pot UI pods in the database pod and they all have their own IP address so to achieve this kubernetes actually the open

source kubernetes doesn't enforce any opinions and so there are ways to achieve this one is to hard hard code routes per node another is to use a network overlay in place of routing tables but ultimately it's you know this this can run into limitations or overhead to be able to just implement base networking features but in gke we actually get a VPC native way of allocating IP addresses to pods so we can within our Google V PC create a known range for these pod IP addresses these are known as IP aliases and then a slash

24 from that range will be assigned to each node to give two pods that are running on that node so we can actually look at that so I also have three nodes in this cluster and we'll look at the pod cider given to each of these nodes and so you'll see here that again what's what's important to note about this is that these are natively implemented in GCPs Sdn right we are not having to say you know creating a route per node to actually implement this and say if you're looking for an address in this

range here go to this node instead our VPC actually handles that natively and is aware of them and so what's really great about that is that this is useful when we're bumping up against quotas for routes and large clusters or for clusters with a hybrid connectivity where we can actually advertise these ranges right but one thing that's core to know about kubernetes pods is that they can come and go which means that these IP addresses that you see here will actually also do the same so kubernetes gives us a stable way of fronting the pods

with a concept called services so let's actually look at some of our services here so let's probably start with our UI service service types build upon each other you'll see here that we have a base cluster IP service and what this means is that we have a stable virtual IP internal to our kubernetes cluster that fronts pods with this key value these key value pairs right so we can actually provide these key value pairs otherwise known as labels in our kubernetes manifests and so this service is actually associated with a dynamic map called endpoints so

if we get endpoints we'll actually see here that I have a map of all of the pod IPS that are running my UI and this endpoint map is actually associated with the UI service so if we scale that UI deployment up and out of pod how many replicas anyone out there six six I think actually I didn't I don't think I enable cluster auto scaling this cuz they say let's let's keep it at four and not go to not go to well so if we actually look at endpoints again we'll actually see some of the

control loops that Wes alluded to in action and so we see that our endpoints object has dynamically been updated to incorporate this new pod that was created right and so as we add more and more pod replicas we can expect this map to be updated and there's actually some magic under the hood where we have a daemon running on every single node configuring IP tables on all of our kubernetes were nodes to forward these stable VIPs to this one of these pot IPS in the endpoints map right and so this was really good we don't

have to think about how we configure load balancing kubernetes kind of makes this so just by declaring our service object what I also want to call out is that like I said services build upon each other so we have an external IP address for our UI pods as well and so if we actually go into the UI we'll see that we'll have network load balancers provision for us and then these will actually route to all of the nodes in our cluster so use cluster has three nodes and then we're back to the IP tables forwarding

to our actual pod traffic so we've actually talked a lot about how we expose an individual service but what happens when we have multiple services which I'm sure your balance you have if you're running in kubernetes engine how do we have a single entry point to route to those services so can we actually cut back to the slides so that's where the kubernetes ingress object comes into play so in gke the default ingress object is actually implemented as our global HTTP low balancer and so if you create an ingress object you'll see here that I

have a service foo and a service bar we're actually able to route users one method is route by path so if we're going to pass foo we're routed to our service foo and then if we route to path bar we're routed to our service bar and so we also expect this to do a lot of basic things at layer 7 like TLS termination but what's really cool about gke is that now we get to again like wes mentioned integrate some of the great GCP services with our kubernetes applications so if we're using the global HTTP

slow bouncer we're actually able to use things like cloud armor to protect against do s attacks we're able to use that Denia where proxy which is basically enforcing a you know identity based access control in front of services cloud CDN and then I want to call out one thing that's really cool and very unique to Google cloud platform and that's Kubb mci so what we can actually do I think as you you know this might not be getting started topic but certainly a lot of customers have directed their or headed in that direction is running

multiple clusters in different geo regions and so with Kubb mci we can actually configure our load balancer not only to front multiple services but to actually front multiple different clusters across the globe and so just a quick demo of that you'll see here that I have 8 can we switch to the demo you'll see here that I have two kubernetes clusters one running in uswest and run one running in europe west and so we also have our global load balancer that has a single IP address right so we have a single single entry point that

is fronting both of our kubernetes engine clusters so if I go to this because we are in wonderful San Francisco we should actually be routed to the US West one a cluster right and what's really cool is that if we actually go into a Europe West one be virtual machine and actually hit that same end point we're going to be we should assuming you don't want to jinx the demo we should be routed to our Europe West cluster and what's really great about this is that previously a lot of people were trying to think about

how to implement this at the DNS layer but what's you know with kubernetes engine and our global load balancer can actually think about this again at the layer layer seven right so if we ping this will actually see that we hit that same IP address and we were served from Europe OS 1b so no tricks up my sleeves this is something that is just really cool and again built into our actual global load balancer using any cast protocol great so going back to the slides the last thing I want to wrap up with as far

as load balancing is really making containers of first-class citizen so as I mentioned before with IP aliases we're able to front IP addresses with known IP addresses through the V PC and what we can actually do with that now is implement something called Network endpoint groups so as I mentioned before there's a lot of IP tables magic in traditional load balancing in kubernetes which could lead to a bunch of extra network hops and really a suboptimal path and I think if you look on the right here we'll see because we are aware of pot IP

addresses we're actually able to configure them as backends to our load balancers in Google cloud platform and so what this makes for is for an experience that makes low balancing much like the way we do it across VMs right we're able to health check against the individual pods we're able to route directly to them without being rerouted through IP tables rules and it really again kind of demonstrates unique properties of google kubernetes engine this is a feature in alpha but certainly keep an eye on it okay so the last tip I have around networking is

sometimes we need private and internal applications to run on kubernetes and so Google tributaries engine also helps you to get enabled with that via private clusters and internal load balancers so private clusters means that all of our virtual machines run air containers are actually running in a private VPC without any access to the public Internet so we can really harden our clusters using private clusters and if we have other applications and the same VPC that are not running in kubernetes engine we can actually also have Network load balancers that are internal to a V PC

great so moving on to the next session now that we have our app in containers and we have a people way for people to access them how do we handle a scenario when a lot more people want to access them and that's where auto scaling comes into play so before we talk about auto scaling it's paramount to introduce a concept of requests and limits the first tip here is use them um they define a floor and ceiling for containers in pods around resources like CPU and memory and they actually inform how our control plane schedules

pods across nodes and you'll see that they actually inform auto scaling a quick note here is that if you define limits for CPU your containers will be throttled at that limit but for memory it's incompressible and so they will actually be killed and restarted so really again it's it's it does require a lot of understanding of what are acceptable kind of resource utilization of your containers cool so the two most well-known auto scaling paradigms are horizontal pod auto scaling and cluster auto scaling so for horizontal plot auto scaling can actually target groups of pods and

scale on metrics like CPU or in gke we can actually provide horizontal pod auto scaling based on custom metrics so if you're doing something like a task queue and you want to track that and scale more pods to handle let's say more work you can configure HPA to do that we also have the concept of cluster auto scaling so eventually if you're scaling up a numerous amount of pods you'll eventually need to add more physical or not visit virtual resources to your kubernetes cluster to run those and that's where cluster auto-scaling comes into play pending

pods that need resources maybe they're not able to be scheduled will trigger cluster auto-scaling to spin out more machines in our node pools and so these two auto scaling paradigms are relatively new but I do think it's important to call out one is being able to scale workloads vertically right so if we want if we think of a compute intensive application maybe like a database you know adding more horizontal replicas won't necessarily solve our issue and so maybe we actually need to scale up the amount of resources that that individual pod has so with vertical

plot auto scaling you'll actually get recommendations that can be either suggested or automatically applied to resize the requests of your pods and then on the right or yeah on the right here you'll see that we also have the ability to scale infrastructure dynamically and so what this means is that if we're if we have a certain set of node pools in our kubernetes cluster but we are you know we don't have any resources to accommodate let's say a 16 CPU request we can actually use something like node auto provisioning to deploy a new node pool

to handle that request that really you know you can scale out as many one CPU machines as you want it's not going to fix that right so node auto provisioning really helps customers that are operating at scale and can't necessarily keep track of every single one of their hundreds of micro services and requests and to have no pools that fit each of those workloads awesome so high availability is important and I'm now gonna kick it over to Wes to tell us more about it awesome all right so try to go through this relatively quickly because

we run a little low on time I'm so H a we added a number of new features actually the last couple months around high availability applications the first one is we added regional persistent disk support to gke quite simply what this does is it replicates your persistent disks across two zones in a region now why is this nice well you don't have to handle replication at the application layer and worry about distributed databases you can just store it all to a PD and Google cloud platform will automatically replicate those two different zones so the abstraction

happens at the storage layer which just get you get out of the box automatically the other concepts around high availability and is what we call regional clusters this is a multi node control plane that spreads both the kubernetes api server and all of the control plant components along with etsy d across three zones in a region now the really nice thing about regional clusters is that it increases the uptime of the cluster to from two and a half 9s to three and a half nines and you get zero downtime upgrades so in the zonal cluster

case we have a single node running your control plan it will go down temporarily when we upgrade the kubernetes version but if you're using regional clusters for your production workloads we'll do a one by one upgrade and we'll always have two two masters ready to serve any workloads that come into the cluster the best part about this is it's available at no additional charge over the zonal clusters we really want everyone to be able to use multi master high availability clusters for their production apps so a few quick tips on upgrades just so people understand

how this works on gke for the control plan google engineers will constantly keep this up to date we will upgrade behind the scenes automatically this is not something you can control outside of a few maintenance window settings that tell us when we can or cannot upgrade your cluster now we we almost never upgrade to the latest version of kubernetes we'll upgrade you to a more stable version that's had a bunch of patch fixes and keep you on that and slowly roll you up to the new to the next version once in another version of kubernetes

comes out you can also trigger this manually if you really want the latest version of kubernetes by going to our cloud console and clicking upgrade now the upgrade for the control plane happens automatically for nodes if you enable auto upgrade it'll work for that as well however if you don't enable auto upgrade this is much more control over when your kubernetes nodes get upgraded to the next version and the thing I wanted to call out is that your cluster can work in this mixed mode state via kubernetes backwards compatibility so we can have nodes running

on 1/8 and a master that's running on 1/10 and we actually won't get to the next version of kubernetes until we go in upgrade the nodes now when you're upgrading your nodes there's a few things to think about you can do the the rolling upgrade that just happens by default and this is just by clicking the the node upgrade button in the window or you can do something called migration with node pools there's a blog post about this on the Google cloud platform blog that goes into much more detail but the short of it is

you can actually create another node pool on the newer version of kubernetes split traffic over to that node pool using Kubik little drain and and cord on and then you can trust test a little bit of the traffic on that new version if you see your app is misbehaving you still have the other node pool that you can route back to the previous version while you debug once the new version looks good you scale that one up and you scale the other node pulldown and we actually see a lot of production users doing this who

want to have a much more testable way of rolling to a new version of kubernetes in the last section is logging and monitoring so I wanted to call out that @q con and Europe this year in Copenhagen we announced stackdriver for kubernetes what this allows you to do is take open source Prometheus instrumentation and ingest that into stack drivers UI and the really cool thing about this is it's multi cluster aggregated and you get to use all of the great stack driver features like the pre-built dashboards and the ability to do things like set alerts

so that you're notified when something goes wrong in your cluster the other feature that we have on gke is gke audit logging so if people are changing your cluster you want to figure out who was the last person to deploy you can go into our logging logging UI understand either and see both pod level and deployment level information along with information about the resources as well so if somebody added a note to your cluster this is the screen that you would go to in order to figure that out now there are a ton more topics

that we just didn't have enough time to cover and 50 minutes things like security identity policy management there's a lot of sessions that are going on that cover these topics and much more depth Anthony I will be outside to help answer any lingering questions you have with that trial gke and thank you very much [Applause] [Music] you