What does HackerNews think of kubernetes-the-hard-way?
Bootstrap Kubernetes the hard way on Google Cloud Platform. No scripts.
https://github.com/kelseyhightower/kubernetes-the-hard-way
Some costs here but click on the google cloud calc as it seems to have gone up since he wrote this: https://github.com/kelseyhightower/kubernetes-the-hard-way/b...
You can always shut it down when not in use to lower costs of course
IMHO - the best way to learn anything is to just sit and hack away, if you wanna get up quickly - read through the docs, make sure you understand the concepts and then grab k3s (or run k3d locally in docker) and deploy something to it. WordPress is a good start.
Take a look at: roadmap.sh/kubernetes If you wanna go all in: https://github.com/kelseyhightower/kubernetes-the-hard-way
Oh, and both: "Kubernetes up and Running" and "Production Kubernetes" are great books.
not sure how up-to-date it is, but it really helped me understand how k8s works.
Are you referring to actually spinning up and operating your own clusters here or utilizing managed k8s (e.g. GKE/EKS)?
In my understanding, sure - using the managed services and deploying simple use cases on it might not be that big of a deal, but running and maintaining your own k8s cluster is likely far more of a challenge [1] than Nomad as I understand it.
[1] https://github.com/kelseyhightower/kubernetes-the-hard-way
You can still deploy apps directly onto Kubernetes and it works very well for this purpose, but it will require a lot more learning than one of the platforms listed above. If you enjoy learning, Kubernetes is an incredibly powerful and satisfying tool to have in your kit, and the initial learning curve isn't as steep as some make it out to be. If your goal is to deploy apps as quickly and simply as possible however, go with one of the pre-existing platforms.
If you still want to learn Kubernetes then a really great book is Kubernetes Up and Running. It goes into just enough detail at the right point in time to make it simple while still being useful. If you do a bit of Googling, you might find a free copy of the book that used to be offered by Microsoft to promote their Azure Kubernetes Service. Otherwise there's Kubernetes the Hard Way² but that's more focused on administering the Kubernetes cluster itself, rather than how to use the cluster to deploy apps. You'd need a pretty convincing reason to administer your own cluster rather than spinning up a managed cluster on GKE or EKS.
My advice: - Grab a copy of Kubernetes Up and Running - Install minikube on your local PC - Experiment and have fun learning
Hope this helps.
---
1. https://twitter.com/kelseyhightower/status/93525292372179353...
2. https://github.com/kelseyhightower/kubernetes-the-hard-way
If you'd like to try kubernetes and get to understand it and feel comfortable with it I'd recommend:
- Work through kubernetes the hard way[1] (ignore/replace the GCP-specific things, if you don't know enough about what the non-GCP corrolary to a GCP-thing is, that's a bit of knowledge you need to fill)
- Set up your own cluster from scratch (no kubeadm, no alternate distros, etc), use the simplest options you can find at first (ex. flannel for CNI)
- Set up ingress (NGINX ingress is a good place to start)
- Run some simple unsecured but diverse workloads (static sites on NGINX, Wordpress, etc), figure out why you might pick a StatefulSet versus DaemonSet. At this point, use the hostPath/local volumes just to avoid trying to grok volume complexity.
- Install a useful cluster tool ("addon") like cert-manager[2] from scratch so you can see Kubernetes manage something you'd normally solve with systemd timers and `certbot` (or your reverse proxy would do for you if you're running caddy or traefik)
- Start putting your YAML in source control get familiar with either kustomize, helm, or both (you could also just use Make + envsubst like I did for a while[3]). It's at this point that it should click that all you need to get back to a certain state of your cluster is to get a machine, do basic hardening (ufw, etc), install kubernetes, and run "make" in this repo (excluding things like DNS entries, etc). Now things are probably getting fun, because you can have the distant cousin of immutable infrastructure; repeatable infrastructure.
- Tear down your cluster, set it up again with kubeadm (note that kubeadm actually has a file-driven configuration option[3]), run your yaml from source control and confirm that all the workloads you had in place are back up and secured.
- (optional) Tear down your cluster, try rebuilding it with k3s[4] or k0s[5]
- Start looking around and seeing what your options are and the ecosystem that exists -- digging deeper into the interfaces that make Kubernetes tick, for example volume management (Container Storage Interface) by deploying Rook[6] or OpenEBS[7].
Note that one of the best things that can happen to you during this process is something going wrong. Every time something goes wrong, and you go back to fundamentals to fix it. Being able to reason about kubernetes ad hoc (ex. if DNS is correct but you can't reach port 80/443, what should you check first?) is the key to feeling comfortable with it, and while failures and downtime will happen, you shouldn't feel just complete despair/confusion. Normally, once things are stable kubernetes is quite worry-free.
I've made a guide like this before, I'll see if I can find it.
[EDIT] Found only one post[8]
[0]: https://vadosware.io/post/fresh-dedicated-server-to-single-n...
[1]: https://github.com/kelseyhightower/kubernetes-the-hard-way
[2]: https://github.com/jetstack/cert-manager
[3]: https://www.vadosware.io/post/using-makefiles-and-envsubst-a...
[4]: https://k3s.io/
[5]: https://docs.k0sproject.io
[6]: https://rook.io/docs
"containers" are often used but not always docker containers. HPC environments I've seen will often use container primitives (e.g. cgroups, namespaces).
There's a lot you can learn with managed Kubernetes and it's a great place to start. You can learn a lot of the parts of Kubernetes with running through https://github.com/kelseyhightower/kubernetes-the-hard-way or reading https://www.amazon.com/Kubernetes-Running-Dive-Future-Infras...
I'll email you to follow-up since tracking HN comments isn't a great way to have a conversation.
That’d be a great first step if the purpose is to learn Kubernetes. If, however, you want to set up a cluster for real use then you will need much more than bare bones Kubernetes (something that solves networking, monitoring, logging, security, backups and more) so consider using a distribution or a managed cloud service instead.
Note: my experience was all with cloud-provided Kubernetes, never running my own. So it was already an order of magnitude easier. Can't even imagine rolling my own. [2]
[1] My personal favorite. Truly egregious, despite how amazing k8s is. https://github.com/kubernetes/kubernetes/issues/63371#issuec...
[2] https://github.com/kelseyhightower/kubernetes-the-hard-way
References:
https://chrisshort.net/kubernetes-illustrated-childrens-guid...
https://docs.google.com/spreadsheets/d/10NltoF_6y3mBwUzQ4bcQ... (The Kubernetes Learning Resources List)
https://github.com/jamiehannaford/what-happens-when-k8s
https://github.com/kubernetes/kubernetes
https://github.com/nkuba/k8s-admin-helper
https://github.com/ramitsurana/awesome-kubernetes
https://github.com/topics/cka?o=desc&s=stars
https://github.com/topics/kubernetes?o=desc&s=stars
https://kubernauts-slack-join.herokuapp.com
https://kubernetes.io/docs/concepts
https://kubernetes.io/docs/reference/kubectl/cheatsheet
https://kubernetes.io/docs/tasks
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/i...
https://kubernetes.io/training
https://kubernetesbyexample.com
https://labs.play-with-k8s.com
https://medium.com/faun/be-fast-with-kubectl-1-18-ckad-cka-3...
https://news.ycombinator.com/item?id=22597880 (Kind - run local Kubernetes clusters using Docker (k8s.io))
https://news.ycombinator.com/item?id=22689119 (Anyone have a recommended guide for Kubernetes?)
https://techbeacon.com/enterprise-it/47-advanced-tutorials-m...
https://www.facebook.com/groups/kubernetes.users
https://www.facebook.com/kubernetesio
https://youtu.be/0Omvgd7Hg1I (Life of a Packet [I] - Michael Rubin, Google)
https://pinboard.in/u:sharjeelsayed/t:kubernetes
Books and Courses:
Certified Kubernetes Administrator (CKA) with Practice Tests by Mumshad Mannambeth
https://kodekloud.com/p/certified-kubernetes-administrator-w...
https://www.udemy.com/course/certified-kubernetes-administra...
https://kodekloud.com/purchase?product_id=1521961&coupon_cod... (Labs - Certified Kubernetes Administrator with Practice Tests)
https://github.com/mmumshad/kubernetes-the-hard-way
https://www.youtube.com/playlist?list=PL2We04F3Y_41lFKy19ig_... (JSON PATH)
https://kodekloud.com/p/json-path-quiz (JSON PATH Quiz- FREE COURSE)
https://join.slack.com/t/kodekloud/shared_invite/zt-dkvyibo4...
https://www.facebook.com/kodekloudtraining
Kubernetes The Hard Way https://github.com/kelseyhightower/kubernetes-the-hard-way
https://linuxacademy.com/course/kubernetes-the-hard-way
https://napo.io/posts/kubernetes-the-real-hard-way-on-aws
https://github.com/mmumshad/kubernetes-the-hard-way
Kubernetes: Up and Running: Dive into the Future of Infrastructure 2nd Edition
https://www.amazon.com/Kubernetes-Running-Dive-Future-Infras...
https://learning.oreilly.com/library/view/kubernetes-up-and/...
More at http://Learn.SharjeelSayed.com
Most of my direct experience with Kubernetes has been on GKE, but I have been meaning to work through https://github.com/kelseyhightower/kubernetes-the-hard-way to gain more appreciation for what is going on behind the scenes.
The end results are similar but the process is vastly different. kubeadm is almost a one-shot tool, doing it the hard way is a learning process. I was trying to say that obviously when you want to just get it done (or script your cluster) then use kubeadm, but if you're learning k8s it's better to do it the hard way at least once. Building an intuition for for the system is made up of (and where to go/which logs to look at when something goes wrong) is important.
> 'The Hard Way' doesn't explain what's going on any more than kubeadm does
Even just following a guide, running the ancillary tools yourself, downloading and running the binaries, etc is way more explanation than kubeadm or other tools give you -- 90% on a fresh machine you just run kubeadm and you're "done" (for some sense of the word).
Before kubernetes the hard way[0] (which is a fantastic resource, though it's gcp specific) existed, I used the CoreOS guides[1] (this was before they started just pushing "use tectonic" and obviously before they were bought out and essentially merged into atomic/fedora/whatever) -- they were fantastic and did more of a walk through of the what and why of the pieces of k8s. Reading through these guides was essential to building my intuition about k8s (I've even written about the process[2]), and I think it's important for people to do this experimentation as well.
One of the best things about k8s is it's ability to unchain you from cloud providers -- using only managed k8s (without something like crossplane[3]) would be effectively squandering that advantage IMO. Yes most companies don't actually need to run multi-cloud, but I expect that the ability to offer k8s as a managed service interface will make it easy for anyone to become/run a cloud provider, and that's a future I want to see -- more cloud providers means more competition which means a better world for startups and those who consume hosting services.
[0]: https://github.com/kelseyhightower/kubernetes-the-hard-way
[1]: https://coreos.com/kubernetes/docs/1.2.2
[2]: https://vadosware.io/post/fresh-dedicated-server-to-single-n...
https://github.com/kelseyhightower/kubernetes-the-hard-way
Really helped me, especially going through it multiple times.
[1] https://github.com/kelseyhightower/kubernetes-the-hard-way
[2] https://www.amazon.com/Kubernetes-Running-Dive-Future-Infras...
Gave me the necessary understanding of the core layers of a cluster.
The Digital Ocean docs were already mentioned but they're also an exellent reference source.
https://github.com/kubernetes/kops
Be aware of this bug at scale ... its interesting
https://blog.quentin-machu.fr/2018/06/24/5-15s-dns-lookups-o...
https://rocketeer.be/blog/2015/11/kubernetes-from-the-ground...
And although I never ran through Hightower's Kubernetes the Hard Way, it is like that. https://github.com/kelseyhightower/kubernetes-the-hard-way
After running through that as a kind of kata, it was easier to infer and troubleshoot things when things go wrong. The transfer-of-learning happens only if you run yourself through these exercises.
I can share some things at a higher level though:
Label selectors are your friend. Master them. They are used everywhere.
Stateless is still easier than stateful. Start with putting stateless workloads in production before ever trying stateful.
If you have the expertise to mix your stateful pods with your stateless pods, make sure you master StatefulSet and things like persistant volume claims.
If you fake stateful pods like I did in production, then Kubernetes does not know how to cleanly shut them down. Automated maintenance involving kubectl cordon and drain no longer function well. You end up having to hand migrate stateful pods from node to node.
Obviously this much more complicated that using a tool such as kubeadm to deploy Kubernetes however it gives you a really good understanding of how a Kubernetes cluster is put together.
One of my colleagues used the experience from working through this with a set of VMs to create a tool called kubicle: https://ciao-project.github.io/kubicle.html
This allows you to build a Kubernetes cluster on your own physical machines by building it on top of a Ciao cluster if you're not able to use public cloud hosted VMs. For learning you can combine this with Ciao's "singlevm"/ccloudvm mode to run a cluster inside a VM (with nested VMs.)
Full disclosure: I currently work on the Ciao team @ Intel :-)
[1] https://www.gitbook.com [2] https://github.com/kelseyhightower/kubernetes-the-hard-way [3] https://gumroad.com [4] https://stackedit.io
If you're interested in books on the topic, I like Kubernetes in Action (https://www.manning.com/books/kubernetes-in-action) or Kubernetes: Up and running (http://shop.oreilly.com/product/0636920043874.do)
One of the challenges with Kubernetes is that it's pretty fast moving, so it's a good idea to work with resources that are up to date. I know a last commit from May doesn't seem very old but that's going to a least be missing 1.7 and could be missing 1.6 or earlier as well.
False. I can relate albeit not having that kind of attention, but had my current manager continually try to hire me for months and get me to interview (which I don't go out of my way saying either because it doesn't make sense to and I want others to think well of me because of my skills--which they often think higher of than I do myself) and she is much more knowledgeable and regarded in the community than me so I am not remotely surprised she was contacted so much and I know for fact that these daily calls DID happen--the ONLY reason she mentioned it was to explain why the process moved so quickly--not so she can go pat herself on the back because she is humble. Maybe you should go look her up on Twitter. She didn't amass a ton of followers for PR/marketing fluff. She's well known in the community due to the contributions she has made and has done a lot of great TECHNICAL things to help people learn e.g. https://github.com/ashleymcnamara/learn_to_code
Developer advocate is a widely used term and you can't assume a general definition. I am a developer advocate myself and part of my role is being a software engineer--I am in an engineering org, report to an engineering manager, and this means I code ON the project just like every other software engineer here, just not as my entire role. The difference is I also speak at conferences, make blogs/training material so that people in the community can learn more about how to use the product(s) (not market fluff). Whether it's coding on their team's project(s), coding on external open source software, or creating demo code, MANY developer advocates are partaking in the technical side themselves and they have to be very knowledgeable to be able to write the technical content in blogs independent of whether it's something they created or not.
You realize this is a post about why she joined, not a general thoughts on the company or a technical overview, right? Therefore it will be the positive things. Also, it can't be just technical merits when you are deciding to join a company. It takes interesting topics and good engineering of course, but also great managers, great team members, a vision, what you'll be working on, etc. She wrote this to explain to people why she switched to Microsoft, not as anything to do with her job.
I, and I am sure others, would appreciate it if you would please get off your high horse and go study up more on facts before you partake in condescending activity yourself by shitting on/slamming someone for something you haven't researched enough on. In this case it could include asking more of "what will you be doing?". And in general, it is best to avoid those types of things in general. Maybe give some technical feedback to posts instead with useful feedback/how to improve things and not dumping on it independent whether you agree with it or not.
Also, go look at some talks/blogs etc from Developer Advocates (and similar titles like Technical Evangelist, Principal Technologist) in the community that include plenty of technical (vs marketing) content and help people learn such as:
Francesc Campoy https://twitter.com/francesc at Google https://github.com/campoy/go-tooling-workshop
Abby Fuller https://twitter.com/abbyfuller at Amazon Web Services https://github.com/abby-fuller/ecs-demo
Scott Hanselman https://twitter.com/shanselman at Microsoft https://www.hanselman.com/blog/
Arun Gupta https://twitter.com/arungupta at Amazon Web Services
Julia Ferraioli https://twitter.com/juliaferraioli at Google (formerly a DA) http://blog.juliaferraioli.com/2015/11/containerized-minecra...
Kelsey Hightower https://twitter.com/kelseyhightower at Google https://github.com/kelseyhightower/kubernetes-the-hard-way
And many others.
Personally I've used Stackpoint.io to provision some small clusters but I was very excited to see this project because deploying my own cluster from scratch is next on my todo list. Kelsey Hightower's "Kubernetes the Hard Way"[1] is the canonical go-to reference here but it's also very daunting so this looks like a great middle ground.
Let's face it, even today the k8s docs can be quite sparse sometimes or gloss over the details, so knowing how all of the pieces work from the ground up can be a big help. Plus, you prevent vendor lock-in when whatever automated tool you're using doesn't solve your use-case or decides to start charging a lot of money.
[1] https://github.com/kelseyhightower/kubernetes-the-hard-way
Looks like bakeoff season...
End result will probably look something like Terraform -> SaltStack -> Kubernetes.
[1] https://kubernetes.io/docs/getting-started-guides/
[2] https://github.com/kelseyhightower/kubernetes-the-hard-way
> Why Kubernetes? (when mesosphere/dcos is available?)
Frankly, if you're familiar and comfortable with DCOS, the core financial benefit is the same: increased hardware utilization, assuming your workload can realize that benefit. And if your application is relatively monolithic and handles the same steady load, I'd advise to stay away from advanced orchestration tools because they're only add moving parts and more complexity, unless you have [1]
> Any available best practices when setting the entire environment from scratch?
For education, I would recommend Kelsey's excellent "Kubernetes the Hard Way": https://github.com/kelseyhightower/kubernetes-the-hard-way
For production, I would recommend Telekube: http://gravitational.com/managed-kubernetes/ It does a lot of extra heavy lifting to make sure your k8s feels like always-on black box (I work there).
[1] Kubernetes also has a "side" benefit of abstracting the underlying infrastructure away, so if you have a use case of running the same complex stack on AWS, colo, vmware, etc then running it on top of a "cloud abstraction layer" lowers your ops/dev costs significantly. We talk about this here: http://gravitational.com/telekube/
https://github.com/kelseyhightower/kubernetes-the-hard-way
Original HN discussion
That said, `kubeadm` is a great addition!
[1] https://github.com/kelseyhightower/kubernetes-the-hard-way