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)
I wrote a beginners guide to Kubernetes
11–17 of 17 posts
Re: I wrote a beginners guide to Kubernetes
#12IMO uni-tools like kubectx are pointless
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.
Re: I wrote a beginners guide to Kubernetes
#13IMO uni-tools like kubectx are pointless 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 wa…
I try to be focused on the results, not the tools per se.
For me, kubectx makes it easier to view and switch between context. I run "kubectx 'context-name'" and it's done :)
Re: I wrote a beginners guide to Kubernetes
#14Thanks! 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)
Thanks for letting me know!
Re: I wrote a beginners guide to Kubernetes
#15IMO uni-tools like kubectx are pointless 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 wa…
> obsoleting "SRE" teams
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.
Re: I wrote a beginners guide to Kubernetes
#16Nice 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 Is…
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.
Re: I wrote a beginners guide to Kubernetes
#17IMO uni-tools like kubectx are pointless 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 wa…
I try to be focused on the results, not the tools per se. For me, kubectx makes it easier to view and switch between context. I run "kubectx 'context-name'" and it's done :)
The results I’m chasing are fewer uni-task tools
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