[holografix]

I would look at these topics and in this order:

1. Containerisation - can you build a hello world web app in any language then Dockerise it.

2. Now break it into two containers - one is the original hello world but now it calls an API on a 2nd container that responds with hello world in one of 10 different languages. Just hard code this the point is that it’s now 2 containers for your “app”.

3. Create a Docker repository in GCP’s Artefact Registry and upload your images. Now remove them from your local Docker registry and run them again but this time pulling them from your registry on GCP.

3. Use Cloudbuild to build them.

4. Spin up a local Kubernetes cluster such as Minikube.

5. Read docos about K8s deployments and service types. Special attention to ClusterService, NodePort, LoadBalancer.

6. Deploy the first version of your hello world. Maybe try to point your YAML to the local registry then the one on GCP you created.

7. Create a service to access your app.

8. Figure out how to turn in and access (via proxy) the kubernetes dashboard.

9. Now deploy the 2nd version of your app. Learn a bit more about K8s networking, pod horizontal scaling, pod resource claims, kill some pods, etc.

10. Learn Skaffold.

11. Create GKE cluster.

12. Deploy same app.

13. Learn about K8s Ingress.

14. Get familiar with GKEs console.

15. Use knowledge of Skaffold to understand and use the brand new Google Cloud Deploy.

Edit: autocorrect “fixed” several things

[epimetheus2]

I've done all this in past and am familiar with it, but I'd be interested in one-step-after-this thing :)

[holografix]

Try Cloud Deploy - it’s a new service and significantly easier than using a self managed CD tool like Spinnaker or Argon.

If you know all of the points I listed before, have a look at GKE benefits like horizontal and vertical pod autoscaling, cluster autoscaling, istio, config connector, anthos

[rad_gruchalski]

Build another app, repeat :)

[fn1]

16. Avoid helm.

[bovermyer]

While I agree generally, this isn't helpful for someone trying to expand their knowledge. Helm is a popular tool, and it's important to understand it, when it's useful, and when it's not.

[grioghar]

Care to elaborate on the three points you mentioned with more specificity?

[bovermyer]

I can, I suppose.

With regards to "understanding it," I mean knowing what it's doing under the hood. It's all well and good to know that you can install something by doing "helm install," but you should really know what helm install actually does.

With regards to "when it's useful," I mean when you have a very complex system that needs a high level of abstraction to make manageable.

With regards to "when it's not [useful]," I mean various scenarios. For example, when you really only need a single pod running with no configuration and no ingress, Helm is not only overkill, but also a negative, as it abstracts without adding any value.

[atmosx]

To my experience helm is great at some things but the fact that does too many things leads to engineers shooting their foot and then you have two problems: K8s and helm problems to solve ;-)

The fact you add complex logic in the chart makes deployment logic problematic when debugging complex workflows because team1 instilled all the logic in the CI while team2 in the helm chart(!) and team3 50-50.

I prefer using bash + gnu utils (envsubst & see) and kustomize than playing around with a template language running on top of another … the funny part was that we run all this thing via Jenkins & bash. I recall having to use an inordinate number of escapes in some cases… anyway.

[mbushey]

> when it's useful: 0% if the time, or possibly more if Self-flagellation is your style

> when it's not: 100% of the time.

[Socketier]

I'm sorry, why is helm so bad exactly?

[szszrk]

Why? What's the alternative?

I see a lot of things that has to be solved on your own even when using Helm. I find their templates repulsive. But "avoid helm" is not an advise, really. How do you suggest to structure, version, deploy, encapsulate with important metadata your deployment descriptions? How do you package it? Is there anything else that integrate with larger tools like Rancher so well?

[jakupovic]

Kustomize look it up, much more native for k8s apps

[Apes]

17. Avoid kustomize even more than Helm.

[mbushey]

Lol. Helm is like the ex that still comes around to key or graffiti your car. Kustomize is the girl that makes you realize you want to get married.

[gonzo41]

Nice list! This is really good on ramp to get functional knowledge fast.

[Turbots]

- Go to https://tanzu.vmware.com/developer/workshops/ and create a free account (the workshops are run inside of your own kubernetes)

- Do the container 101 hands-on workshop (bottom of the page)

- Do the Kubernetes 101 hands-on workshop

- ???

- Profit! build and deploy applications on ANY kubernetes (not just GCP)

And then look into the GCP specifics for k8s (GKE), networking, DNS, load balancing, storage, monitoring, etc...