-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Summarize EKS on K8 into github readme file #6545
Comments
Kubernetes LearningPurposeThe purpose of this document is to summarize our thoughts and feelings about how an engineer new to Kubernetes might go about gaining some practical, useful experience with it, based on our recent experiences doing just that. This document is tailored to engineers and assumes some experience with DevOps, Linux system administration, or similar subjects. Kubernetes is a container orchestration platform based on clustering, and its design decisions have followed from that premise. As a result, it is critical to have a working understanding of networking (ideally including a casual familiarity with I believe that the best way to grasp any sort of technology is to use it yourself; I think that's why we use "grasp" as a synonym for "understand", especially with regards to technology. So I think it's essential to dive right in to Kubernetes by deploying a cluster, suffering through the inevitable complications and setbacks encountered along the way, and maintaining and improving it as you learn. This can be done a number of ways. EKS is the foundation of our infrastructure with regard to Kubernetes, but I feel this is a suboptimal choice for learning. EKS was developed with an eye to the pain points of Kubernetes: managing ingress/load balancing, deployment, upgrades and other maintenance to the cluster itself, and so forth. It's tightly integrated with AWS' innumerable other offerings, making it comparatively easy to add storage, to log in a persistent fashion, to manage TLS certificates, and so forth. EKS is a solid option, but the fact that it eliminates or eases some of these struggles ultimately presents some barriers to understanding. It also costs money; not much, comparatively speaking, and the resources can of course be created and destroyed on demand as one would any other AWS resource. But some challenges with Kubernetes present themselves only over time, and this expense will accumulate. I think it is preferable to avoid the cloud and deploy and maintain a cluster locally -- either virtualized or on bare metal. Some distributions of Kubernetes can run and do useful work on two or three Raspberry Pis, or two or three virtual machines running in VirtualBox, or even within a couple of Docker containers. I think it's preferable to avoid options that don't provide a 1:1 match for functionality with a standard Kubernetes distribution, but all options provide significant and irreplaceable value. In our cases, we took two different approaches:
We documented our experiences with getting a cluster running in this GitHub issue. The factors in your decision-making may (and likely will) differ from ours and lead to different choices and different avenues of investigation. This is a good thing. Kubernetes is large and complex, built on many different technologies at different levels, and developing rapidly. However, its sheer breadth should provide toeholds while you learn. We've found these resources to be useful and worth checking out: Videos:
Core Tools:
Extra Tools:
Kubernetes, the Hard Way:
Kubernetes Distributions:
Just For Fun:
Links/References:
|
Added a document about our architecture here. |
Background
As an engineer, I can read a clear summary of the EKS on K8 discovery findings and approach per
https://app.zenhub.com/workspaces/vagov-cms-team-5c0e7b864b5806bc2bfc2087/issues/department-of-veterans-affairs/va.gov-cms/6355
Acceptance Criteria
The text was updated successfully, but these errors were encountered: