Nice article, I liked the heavy focus on networking. Looking forward to the next part. If I could make a request it would be for the inclusion of Istio somewhere in in the following parts
IMHO, its a beginners guide and the focus on networking was to make beginners understand basic concepts - heavy focus would mean the guide would explain how k8s networking works under the hoods which is often important in real production environment, where you will face various issues.
When it comes to Istio - its a complex solution by itself and deserves a separate guide. I would say beginners should try to learn Istio when they are no longer beginners but rather advanced k8s users or even maintainers.
We are looking at deploying Kubernetes on GCP as a managed service (GKS) - will we have to deal with networking issues in production, or is this something abstracted away by the managed service?
I know that ELBs for external traffic ingress are automatically managed by GCP, but not sure what other things we need to consider.
Thanks! You can add that if the docker-desktop context is not available, you can enable it in Docker preferences -> Kubernetes -> Enable Kubernetes (I had to do this)
Learning a bespoke tool to run one bash command is poor craftsmanship, won’t be worth knowing about once Kube is entirely wrapped by some providers HTTP API, and this is all managed by GUI based services, obsoleting “SRE” teams at places that aren’t Google scale
The excitement of Kube will go the way Puppet and Chef have. It’s just HTTP commands putting some YAML or JSON which is metadata for how to manage cgroups
Oh right but Google and Oreilly flooded the world with books, so kiss the rings.
I'm not sure this follows. Having GUI tools that do everything works great until you have a use-case outside of the scope of the tool, or something goes wrong, then you'll need to learn the inner workings of the tool anyway (if you're lucky enough to be able to access the tool behind the managed service).
I've seen this with all manner of managed databases, as well as with Amazon ECS and Fargate.
Not to say that you're wrong about kubectx, just that I don't agree with the logic.
Edit: On an unrelated note, I just realized that I compulsively and without thinking replaced the left/right quotation marks after copying the text from your comment.
16 comments
[ 4.0 ms ] story [ 50.8 ms ] threadI am about to release a new Kubernetes based machine learning product (using new CRDS, operators, etc).
I wonder if you can you do a paid review? we can talk offline if needed.
When it comes to Istio - its a complex solution by itself and deserves a separate guide. I would say beginners should try to learn Istio when they are no longer beginners but rather advanced k8s users or even maintainers.
I know that ELBs for external traffic ingress are automatically managed by GCP, but not sure what other things we need to consider.
Huge fan of fzf + bash history
Trigger fzf, search “context cluster-name” done
Learning a bespoke tool to run one bash command is poor craftsmanship, won’t be worth knowing about once Kube is entirely wrapped by some providers HTTP API, and this is all managed by GUI based services, obsoleting “SRE” teams at places that aren’t Google scale
The excitement of Kube will go the way Puppet and Chef have. It’s just HTTP commands putting some YAML or JSON which is metadata for how to manage cgroups
Oh right but Google and Oreilly flooded the world with books, so kiss the rings.
For me, kubectx makes it easier to view and switch between context. I run "kubectx 'context-name'" and it's done :)
Ctrl+r to get fzf, searching “context prod” pulls up my last use of the kubectl form of the change context command
Desired results are subjective
I'm not sure this follows. Having GUI tools that do everything works great until you have a use-case outside of the scope of the tool, or something goes wrong, then you'll need to learn the inner workings of the tool anyway (if you're lucky enough to be able to access the tool behind the managed service).
I've seen this with all manner of managed databases, as well as with Amazon ECS and Fargate.
Not to say that you're wrong about kubectx, just that I don't agree with the logic.
Edit: On an unrelated note, I just realized that I compulsively and without thinking replaced the left/right quotation marks after copying the text from your comment.