Starting with Kubernetes Engine: Developer-friendly Deployment Strategies (Cloud Next '18)

Google Kubernetes Engine is suitable for projects of all sizes. Even if you’re starting with a single VM deployment, using GKE sets you up to handle growth. It takes advantage of a comprehensive set of workload primitives and runs with little or no maintenance. In this talk, we cover the benefits of starting with Kubernetes, configuring developer-friendly deployments, and planning for growth.
Learn about newly announced features of GKE, how to configure git push-to-deploy development pipelines, and how to take advantage of GKE’s automated operations like resizing and auto repair.
DEV106
Event schedule → g.co/next18
Watch more Application Development sessions here → bit.ly/2zMcTJc
Next ‘18 All Sessions playlist → bit.ly/Allsessions
Subscribe to the Google Cloud channel! → bit.ly/NextSub
re_ty: Publish; product: Cloud - Containers - Google Kubernetes Engine (GKE); fullname: William Denniss; event: Google Cloud Next 2018;

[@VladimirMinkin]

One of the best talk about GKE I've ever seen. Very professional, thank you!

[@ragy1986]

Agree! That was great. One of the few talks labelled for developers that was actually for developers!

[@beckettzakai6070]

sorry to be so offtopic but does any of you know of a way to log back into an Instagram account??
I somehow lost the password. I would love any help you can offer me!

[@elifuchs9580]

Excellent presentation and demo's.

[@alex.ssanya]

GKE well explained

[@j.d.5262]

MAN that loud ending.. made me jump!

[@glopena3986]

Is there a way to limit the scale up on budget rather than number of nodes? e.g. My monthly budget is X, stop scaling up if the cost projection could surpass the grant?
Thanks. Really nice talk.

[@ishwarabhat]

You could set budget limits in GCP project at granular resource type level, right?

[@Yggdrasil42]

You can set a maximum for a nodepool, meaning it won't scale above that. That'll get tricky if you have multiple nodepools or clusters, at which point you're better off setting a billing budget and getting alerted when you're close to your monthly maximum or when you're exceeding your expected daily average.

[@Jayesh_u]

Clearly shows the power of Kubernetes on top of GKE

[@petermelnikov682]

22:26 having branches for different environments is actually a bad practice. It does not scale well (you may want to add a new environment for a demo, or spin off an on-demand temp cluster), it requires you to build artefacts multiple times to promote from one environment to another, you may end up in situation when you code diverges.

[@howardh6857]

I think that's the point of branches, is to merge back as soon as possible. A new env would be a branch, just call it demo and this would likely have changes not related to nonprd or prd. The cluster is not limited to the repo or branch so you can use the controller to mange that. I like the design he mentions.