[user-journeys] Content for the application developer persona #6907
Conversation
k8s-ci-robot
added
do-not-merge/work-in-progress
|
Deploy preview for kubernetes-io-user-journeys ready! Built with commit 29fa6b8 https://deploy-preview-6907--kubernetes-io-user-journeys.netlify.com |
|
To fix travis build, we'll eventually have to rebase off master...going to wait for the entire |
jesscodez
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
|
||
| Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit. | ||
| Kubernetes provides ways to attach metadata or inject data into your resources: | ||
| * **Taints and Tolerations** - These provide a way for nodes to "attract" or "repel" your Pods. [Read more](/docs/concepts/configuration/taint-and-toleration/){:target="_blank"}. |
There was a problem hiding this comment.
For an app developer, their primary use will be identifying hardware(nodes) with specific capabilities, or limitations - i.e. this one has a GPU, or requires arm64 architecture images...
| Kubernetes provides ways to attach metadata or inject data into your resources: | ||
| * **Taints and Tolerations** - These provide a way for nodes to "attract" or "repel" your Pods. [Read more](/docs/concepts/configuration/taint-and-toleration/){:target="_blank"}. | ||
| * **Downward API** - This allows your containers to consume information about themselves or the cluster, without being overly coupled to the Kubernetes API server. This can be achieved with [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/){:target="_blank"} or [DownwardAPIVolumeFiles](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/){:target="_blank"}. | ||
| * **ConfigMaps** - This was mentioned in the beginner section, and is worth another highlight because it is a common way to decouple runtime-specific parameters from your container images. [Read more](/docs/tasks/configure-pod-container/configure-pod-configmap/){:target="_blank"}. |
There was a problem hiding this comment.
Highly recommend you call out Secrets right next to ConfigMaps. Still a long way to go to get to something like vault for k8s, but best to highlight the better practice of using secrets here
There was a problem hiding this comment.
And in a not unrelated issue -- do we want to call out Secrets as part of a larger topic about security? Also note to all of us on user journeys to figure out which user journey should really focus on security, and maybe clarify distinctions between roles around the issue?
| #### Resource isolation and management | ||
|
|
||
| If your workloads may be operating in a **multi-tenant** environment with multiple teams or projects, your container(s) are *not* necessarily running alone on their node(s). They are sharing node resources with other containers which you do not own. | ||
|
|
There was a problem hiding this comment.
You might also put in a link and mention Quality of Service, especially as Pod Priority is starting to get some serious traction in 1.9 and eviction/pre-emption could be a thing where the QoS rating makes a material difference in if your Pod's stay running vs. others with a better QoS assignment
|
|
||
| The beginner tutorials on this site (e.g. [Guestbook](/docs/tutorials/stateless-application/guestbook/){:target="_blank"}) are geared towards getting workloads up-and-running on your cluster. This sort of prototyping is great for building your intuition around Kubernetes! However, in order to reliably and securely promote your workloads to production, you'll need to follow some additional best practices. | ||
|
|
||
| #### Declarative configuration |
There was a problem hiding this comment.
A reference to audit tracking from declarative management might be useful here, relatively new feature - more of interest to SREs, but I think developers might find it useful as well
There was a problem hiding this comment.
Also a good idea for managing security (RBAC configurations come to mind). Good for devs to be aware of, and another item for cross-referencing to cluster ops
|
|
||
| Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam. | ||
| Based on the ideas above, there is no reason you can't define a completely new [Custom Resource](/docs/concepts/api-extension/custom-resources/#custom-resources){:target="_blank"} that is just as legitimate as a Deployment. For example, you might want to define a `Backup` object for periodic backups, if `CronJobs` don't provide all the functionality you need. | ||
|
|
There was a problem hiding this comment.
probably a personal bias here, but I always thought of extending the K8S api with CRD's as pretty much the height of complexity, so perhaps more relevant for the advanced section?
|
|
||
| Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi. | ||
| ## Extend the Kubernetes API |
There was a problem hiding this comment.
I'm with Joe on CRDs, but also I think wrt this entire section. It would be excellent content for the advanced app developer, though -- perhaps also more explicitly divided into conceptual and task-based content.
|
|
||
| Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam. | ||
| Based on the ideas above, there is no reason you can't define a completely new [Custom Resource](/docs/concepts/api-extension/custom-resources/#custom-resources){:target="_blank"} that is just as legitimate as a Deployment. For example, you might want to define a `Backup` object for periodic backups, if `CronJobs` don't provide all the functionality you need. |
There was a problem hiding this comment.
Definitely agree with Joe here, and am not sure the tone of this section is right even for an advanced app developer. Writing CRDs isn't exactly hard, but it's non-trivial, and these sentences suggest that if you aren't sure about an existing K8s object, just go write your own. Ummmmm. Not sure backups is/are a good example, either ... The larger point is important, but I'm wondering whether we want to invite a more considered approach to CRDs.
| ## Additional resources | ||
| There are two main ways of setting up custom resources: | ||
| 1. **Custom Resource Definitions (CRDs)** - See [an example](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/){:target="_blank"}. | ||
| 2. **API aggregation** - This requires some [pre-configuration](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/){:target="_blank"} before you actually [set up a separate, extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/){:target="_blank"}. |
There was a problem hiding this comment.
And now we're really into advanced territory!
|
|
||
| The beginner tutorials on this site (e.g. [Guestbook](/docs/tutorials/stateless-application/guestbook/){:target="_blank"}) are geared towards getting workloads up-and-running on your cluster. This sort of prototyping is great for building your intuition around Kubernetes! However, in order to reliably and securely promote your workloads to production, you'll need to follow some additional best practices. | ||
|
|
||
| #### Declarative configuration |
There was a problem hiding this comment.
Also a good idea for managing security (RBAC configurations come to mind). Good for devs to be aware of, and another item for cross-referencing to cluster ops
|
|
||
| ## Deploy an application with advanced features | ||
| (*Note that not all Kubernetes objects need to have a Controller. Though Deployments trigger the cluster to "do things", ConfigMaps act purely as storage.*) |
There was a problem hiding this comment.
I think this would be a good idea to wrap/note with the {: .note} format?
|
|
||
| Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit. | ||
| Based on the ideas above, there is no reason you can't define a completely new [Custom Resource](/docs/concepts/api-extension/custom-resources/#custom-resources){:target="_blank"} that is just as legitimate as a Deployment. For example, you might want to define a `Backup` object for periodic backups, if `CronJobs` don't provide all the functionality you need. |
There was a problem hiding this comment.
rather than "this is no reason you can't", this might be better with active wording: "you can"
| Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam. | ||
| There are two main ways of setting up custom resources: | ||
| 1. **Custom Resource Definitions (CRDs)** - See [an example](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/){:target="_blank"}. | ||
| 2. **API aggregation** - This requires some [pre-configuration](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/){:target="_blank"} before you actually [set up a separate, extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/){:target="_blank"}. |
There was a problem hiding this comment.
not sure the , is needed between separate and extension
|
|
||
| Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi. | ||
| Note that unlike standard Kubernetes objects, which rely on the built-in [`kube-controller-manager`](/docs/reference/generated/kube-controller-manager/){:target="_blank"}, you'll need to write and run your own [custom controllers](https://github.com/kubernetes/sample-controller). |
There was a problem hiding this comment.
Maybe drop the "Note that unlike standard" and just lead this with "Unlike built-in"? (replacing standard with built-in)
| Kubernetes provides ways to attach metadata or inject data into your resources: | ||
| * **Taints and Tolerations** - These provide a way for nodes to "attract" or "repel" your Pods. [Read more](/docs/concepts/configuration/taint-and-toleration/){:target="_blank"}. | ||
| * **Downward API** - This allows your containers to consume information about themselves or the cluster, without being overly coupled to the Kubernetes API server. This can be achieved with [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/){:target="_blank"} or [DownwardAPIVolumeFiles](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/){:target="_blank"}. | ||
| * **ConfigMaps** - This was mentioned in the beginner section, and is worth another highlight because it is a common way to decouple runtime-specific parameters from your container images. [Read more](/docs/tasks/configure-pod-container/configure-pod-configmap/){:target="_blank"}. |
There was a problem hiding this comment.
probably also worth mentioning Secrets at the same time as ConfigMaps
|
|
||
| Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit. | ||
| * [Commonly used `kubectl` commands](/docs/reference/kubectl/cheatsheet/){:target="_blank"} | ||
| * [Kubernetes API reference](/docs/reference/generated/kubernetes-api/v1.9/){:target="_blank"} |
There was a problem hiding this comment.
should we replace v1.9 with some inline tag thing that references the "current version of Kubernetes"? Not sure what common best practice is on this...
| @@ -9,80 +9,151 @@ track: "USERS › APPLICATION DEVELOPER › FOUNDATIONAL" | |||
| --- | |||
|
|
|||
| {% capture overview %} | |||
| If you're an application developer looking to get started with Kubernetes, this page and its linked topics introduce you to foundational concepts and tasks. The focus is on a development workflow -- check out other user journeys to learn about managing production clusters, or providing high availability (HA) for critical application deployments. | |||
| If you're a developer looking to run applications on Kubernetes, this page and its linked topics should help you get started with the fundamentals. Though this level primarily describes development workflows, [subsequent levels](/docs/home/?path=users&persona=app-developer&level=intermediate){:target="_blank"} cover more advanced, production setups. | |||
|
|
|||
There was a problem hiding this comment.
Suggestion: should help -> can help
| ##### **A quick note** | ||
| Generally, app developers can focus more on *what* they're deploying to Kubernetes, rather than *how* the underlying infrastructure works. Though it's possible for a single person to manage both, in many organizations, it’s common to assign the latter to a dedicated {% glossary_tooltip text="cluster operator" term_id="cluster-operator" %}. The cluster operator takes on the responsibility of setting up and maintaining Kubernetes clusters. | ||
|
|
||
| As a result, the app developer "user journey" is *not* a comprehensive overview of Kubernetes. It does, however, highlight the aspects of cluster admin that are most relevant to development, testing, and deployment at the application level. | ||
|
|
There was a problem hiding this comment.
In the previous paragraph, you said "cluster operator." Here you say "cluster admin". Suggestion: Use the same term in both places.
|
|
||
| One good way to learn Kubernetes basics is with Minikube, which lets you create a simple single-node cluster with all core Kubernetes components. If you install locally, you may find that your cluster is sufficient for local application development. Installing Minikube locally is also a good idea if you want to continue exploring in a persistent environment that you can come back to and change. | ||
| #### Web-based Environment | ||
|
|
There was a problem hiding this comment.
Somewhere in here we should link to our own web-based environment: Kubernetes Basics.
|
|
||
| You can deploy a simple application in Kubernetes with a Deployment manifest, also called a configuration or config file, or sometimes a spec. The manifest is written in YAML or JSON, and describes the desired state of the application and related resources as Kubernetes should maintain them. | ||
| * *(Optional)* [Install Docker](/docs/setup/independent/install-kubeadm/#installing-docker){:target="_blank"} if you plan to run your Minikube cluster as part of a local development environment. | ||
|
|
There was a problem hiding this comment.
"push containers" might not be clear to newcomers. Suggestion: "to create containers and push them to a container repository ..."
| * A Volume lets you define storage for your cluster that is tied to the lifecycle of a Pod. It is therefore more persistent than container storage. Learn [how to configure volume storage](/docs/tasks/configure-pod-container/configure-volume-storage/), or [read more about about volume storage](/docs/concepts/storage/volumes/). | ||
| * A PersistentVolume and PersistentVolumeClaim let you define storage at the cluster level. Typically a cluster administrator defines the PersistentVolume objects for the cluster, and cluster users (application developers, you) define the PersistentVolumeClaim objects that your application requires. Learn [how to set up persistent storage for your cluster](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/) or [read more about persistent volumes](/docs/concepts/storage/persistent-volumes/). | ||
| You can get basic information about your cluster with the command `kubectl get nodes`. To get a good idea of what's really going on, however, you need to deploy an application to your cluster. This is covered in the next major section. | ||
|
|
There was a problem hiding this comment.
Suggestion: with the commands kubectl cluster-info and kubectl get nodes.
|
|
||
| The following examples demonstrate how to deploy basic apps to Kubernetes: | ||
| * [Deploy a simple, stateless nginx server](/docs/tasks/run-application/run-stateless-application-deployment/){:target="_blank"}. Nginx is often used as the web server to help provide ingress from outside your cluster (in other words, external requests). | ||
|
|
There was a problem hiding this comment.
I don't like saying that nginx helps provide ingress. Soon, the reader will come to the Service and Ingress API objects. Using the word "ingress" here could lead to confusion.
I think we could just strike the whole sentence.
| * Fundamentals | ||
|
|
||
| * **Kubernetes manifests** - These configuration files describe the desired state of your application and related resources as Kubernetes should maintain them. They are written in YAML or JSON. (See the [example from the nginx app](/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment)) | ||
|
|
There was a problem hiding this comment.
I think it's good to maintain a distinction between manifest and file. A single file could contain several resource manifests. Maybe this:
Configuration files - These files describe ...
|
|
||
| Labels let you specify identifying information for Kubernetes objects that you define, such as pods. This information is entirely user-defined, and is used to sort and select sets of objects. | ||
| * **{% glossary_tooltip text="Ingress" term_id="ingress" %}** - A general API object that determines routing rules, such as how to handle traffic requests between your cluster and the outside world. | ||
|
|
There was a problem hiding this comment.
Suggestion: A general API object -> An API object.
Suggestion: Instead of "traffic requests", use "traffic" or use "requests".
| * **{% glossary_tooltip text="Ingress" term_id="ingress" %}** - A general API object that determines routing rules, such as how to handle traffic requests between your cluster and the outside world. | ||
|
|
||
| * **{% glossary_tooltip text="Service" term_id="deployment" %}** - By itself, a Deployment can't provide ingress. This is one of the simplest ways to configure ingress, as it supports load balancing and {% glossary_tooltip text="label" term_id="labels" %} selection. | ||
|
|
There was a problem hiding this comment.
Because we're making a distinction between Ingress and Service objects, let's not use the word "ingress" to define and explain Service.
| * [Deploy a stateful, externally accessible MySQL database](/docs/tasks/run-application/run-single-instance-stateful-application/){:target="_blank"}. This introduces the concept of storage. | ||
|
|
||
| Through these deployment tasks, you'll gain familiarity with the following concepts: | ||
| * Fundamentals |
There was a problem hiding this comment.
This introduction seems to say that by doing the suggested tasks, you will gain familiarity with configuration files, Pods, Deployment, Ingress, and Service.
But I don't see any use of an Ingress object in the suggested tasks.
Also, saying that the MySQL database is externally accessible might be misleading. In the task, the MySQL client runs in a Pod in the same cluster as the MySQL instance. The Service that is created in the task is the kind of Service that enables communication between Pods, not communication between Pods and the outside world.
| {% glossary_tooltip text="Labels" term_id="labels" %} let you specify identifying information for Kubernetes objects that you define, such as pods. This information is entirely user-defined, and is used to sort and select sets of objects. | ||
|
|
||
| * When you previously [created a basic nginx Deployment](/docs/tasks/run-application/run-stateless-application-deployment/){:target="_blank"}, you specify the `app: nginx` label as part of the template metadata. The `matchLabels` selector then specifies this label as part of the spec. | ||
|
|
There was a problem hiding this comment.
Let's not assume the reader previously did something or read something. Instead, let's say something like this:
In the Stateless Application task, ...
Also, I don't think this explanation will be clear to newcomers. For example, you mention the template field and the spec field, but you don't say what kind of objects those are. I'll revisit this comment later today to offer some suggested alternatives.
| The subsequent sections here describe other useful areas to know for app deployment. | ||
|
|
||
| #### Metadata | ||
|
|
There was a problem hiding this comment.
This section seems to be about labels, but not about any other kind of metadata. Let's use the heading Labels instead of the heading Metadata.
|
|
||
| ## How Kubernetes works: an introduction | ||
| To provide configuration data for your application, you can specify Kubernetes environment variables as part of the container definition in your Deployment manifest. However, this may require you to rebuild your container or modify your Deployment. | ||
|
|
There was a problem hiding this comment.
This doesn't ring true to me. You can specify environment variables for a Container without rebuilding the Container. See Define Environment Variables for a Container.
Also, let's just call them "environment variables", not "Kubernetes environment variables".
|
|
||
| To work with Kubernetes, you describe your cluster's desired state in terms of Kubernetes API objects. Cluster state includes but is not limited to the following information: | ||
| To decouple configuration data from your workload, you can also use the following objects: | ||
|
|
There was a problem hiding this comment.
I'd like to see us touch on one other way to inject data into applications: Expose Pod Information to Containers Through Files.
| ## Understand Kubernetes basics | ||
|
|
||
| As an app developer, you don't need to know everything about the inner workings of Kubernetes, but you may find it helpful to understand it at a high-level. | ||
|
|
There was a problem hiding this comment.
high-level -> high level.
| If you're not running Kubernetes or a similar automated system, you might find the following scenario familiar: | ||
| 1. One instance of your app (a complete machine instance or just a container) goes down. | ||
| 2. Because your team has monitoring set up, this pages the person on-call. | ||
| 3. The on-call has to go in, investigate, and manually spin up a new instance. |
There was a problem hiding this comment.
pages the person on call. (no hyphen)
The on-call person has to go in,
the on-call person may also need to ...
| **If you have Kubernetes set up, however, manual intervention is not as necessary.** Kubernetes will gracefully handle (3) and (4) on your behalf. As a a result, it's often referred to as a *self-healing* system. | ||
|
|
||
| On a high-level, there are two key concepts to making this work: the *Kubernetes API* and the *Control Plane*. | ||
|
|
There was a problem hiding this comment.
high-level -> high level
|
|
||
| **If you have Kubernetes set up, however, manual intervention is not as necessary.** Kubernetes will gracefully handle (3) and (4) on your behalf. As a a result, it's often referred to as a *self-healing* system. | ||
|
|
||
| On a high-level, there are two key concepts to making this work: the *Kubernetes API* and the *Control Plane*. |
There was a problem hiding this comment.
The Kubernetes API is not a concept. Likewise, the Control Plane is not a concept. I'll revisit with a suggested alternative.
|
|
||
| Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi. | ||
| The beginner tutorials on this site (e.g. [Guestbook](/docs/tutorials/stateless-application/guestbook/){:target="_blank"}) are geared towards getting workloads up-and-running on your cluster. This sort of prototyping is great for building your intuition around Kubernetes! However, in order to reliably and securely promote your workloads to production, you'll need to follow some additional best practices. |
There was a problem hiding this comment.
up-and-running -> up and running
|
|
||
| Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam. | ||
| You are likely interacting with your Kubernetes cluster via {% glossary_tooltip text="kubectl" term_id="kubectl" %}. `kubectl` can be used to debug the current state of your cluster (such as checking the number of nodes), or to update the configurations of actual Kubernetes objects (e.g. updating the replica count with `kubectl autoscale`). |
There was a problem hiding this comment.
I think it's more accurate to say, "updating the replica count with kubectl scale". (not autoscale)
|
|
||
| Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam. | ||
| You are likely interacting with your Kubernetes cluster via {% glossary_tooltip text="kubectl" term_id="kubectl" %}. `kubectl` can be used to debug the current state of your cluster (such as checking the number of nodes), or to update the configurations of actual Kubernetes objects (e.g. updating the replica count with `kubectl autoscale`). |
There was a problem hiding this comment.
I don't think it's correct to say, "update the configurations of actual Kubernetes objects". I think in this case, you're talking about updating the objects, not the configurations of the objects. Suggestion: "or to update live Kubernetes objects".
|
|
||
| Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi. | ||
| When using `kubectl` to update your Kubernetes object configurations, it's important to be aware that different `kubectl` commands correspond to different approaches: |
There was a problem hiding this comment.
object configurations -> objects
|
|
||
| Curabitur bibendum tempor mi, vel lacinia nisi vulputate ac. Nulla dignissim consectetur nisl nec tincidunt. Etiam pharetra facilisis sapien, non gravida velit fermentum sed. Ut ac ultrices nunc, in vestibulum urna. Suspendisse accumsan euismod felis, sit amet rhoncus neque volutpat luctus. Aliquam tincidunt pellentesque mauris, sed tempus diam. Mauris in elit eget justo tempor suscipit. | ||
| There are pros and cons to each approach, though the *declarative approach* (e.g. `kubectl apply -f`) may be most helpful in production. Relying on local YAML files as the source of truth allows you to track and version control your configuration. |
There was a problem hiding this comment.
Even though you don't say it directly, this seems to say that the source of truth for the cluster lies in the local YAML files. If we're going to say "source of truth", I think we need to say something like "source of truth about your desired state".
|
|
||
| #### Security | ||
|
|
||
| You may be familiar with the principle of least privilege---if you are too generous with permissions when writing or using software, during a compromise, the negative effects can escalate out of control. Would you be cautious handing out `sudo` privileges to software on your OS? If so, you should be just as careful when granting your workload permissions to the Kubernetes API server (which is your cluster's source of truth!). |
There was a problem hiding this comment.
Saying the API server is the source of truth makes me nervous. I see the source as the state stored in etcd. The server passes the truth along to those who ask.
| * **[Memory](/docs/tasks/configure-pod-container/assign-memory-resource/){:target="_blank"} and [CPU](/docs/tasks/configure-pod-container/assign-cpu-resource/){:target="_blank"} requests**, for a given Pod or container | ||
|
|
||
| Although this list may not be completely comprehensive, the Kubernetes documentation is fairly rich and details other topics like [monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/){:target="_blank"} and [Ingress](/docs/concepts/services-networking/ingress/){:target="_blank"}. On the other hand, your team may already have existing processes that take care of all of the topics just covered! | ||
|
|
There was a problem hiding this comment.
Suggestion: Strike this last paragraph. Add the "monitoring" link to the bulleted list. I don't think Ingress belongs under Resource Isolation and Management.
|
|
||
| Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean id felis non enim faucibus lacinia. Aliquam massa mauris, interdum a ex ut, sagittis rutrum nulla. In pellentesque est at molestie fringilla. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec eu mi at velit lacinia venenatis ac nec sem. In volutpat pellentesque dui ut commodo. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis sollicitudin eleifend felis non facilisis. Pellentesque leo urna, congue id auctor non, varius a nunc. Duis ultrices, odio ut hendrerit suscipit, nisi mauris dignissim mauris, nec bibendum ante neque ut augue. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nam condimentum libero sit amet rutrum fermentum. Proin posuere condimentum odio. Aenean volutpat, ex vel tincidunt tincidunt, massa odio condimentum lectus, vel iaculis libero dolor in nisi. | ||
| Now that you're fairly familiar with Kubernetes, you may find it useful to browse the following reference pages to get a high-level view of what other features may exist: |
There was a problem hiding this comment.
may exist -> exist
In general, I think you could reduce your use of "may".
|
|
||
| Aenean suscipit arcu ac leo tincidunt tempus. Donec maximus tellus libero, ac ullamcorper magna lobortis ac. Integer mollis nisl vitae magna gravida, nec ornare ex consectetur. Sed mattis tincidunt nisi, at consequat tellus malesuada non. Integer vel semper nisi, ut fringilla velit. Nam felis ex, congue non dui vitae, sollicitudin convallis turpis. Phasellus porttitor maximus turpis, in varius nibh fermentum aliquam. Cras finibus lacus non diam porttitor porttitor. Nulla fringilla sagittis nibh nec condimentum. Duis egestas mauris nec dolor hendrerit ullamcorper sit amet in mi. Phasellus sollicitudin justo diam. | ||
| Also, although it is not official documentation, [the Kubernetes blog](http://blog.kubernetes.io/){:target="_blank"} often has helpful posts on Kubernetes design patterns and case studies. |
There was a problem hiding this comment.
Suggestion: Strike "although it is not official documentation". It sounds like an apology.
|
@abiogenesis-now Thanks so much for taking the lead on this. I've finished my review pass. |
|
thank you for the thorough review @steveperry-53 ! I'll be revising later today; your feedback looks extremely helpful! |
k8s-ci-robot
added
the
approved
jesscodez
changed the title
k8s-ci-robot
added
the
do-not-merge/work-in-progress
jesscodez
removed
the
approved
k8s-ci-robot
added
size/XL
|
not sure why the bot keeps adding approvals, i'll just ignore them for now |
jesscodez
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
jesscodez
changed the title
|
This PR is ready for review! One CI test is failing, but that’s due to something fixed upstream, so it should (?) be resolved by merging this PR into the main user-journeys branch, and rebasing that branch against master. |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abiogenesis-now, chenopis The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
Still need to add some more content, will update when done.
@chenopis FYI
Ended up revising "foundational" level and adding the "advanced" level, in addition to writing the "intermediate" content.
This change is