AWS eks documentation change
Summary
Fixed typos and grammatical improvements in stateless applications and Services sections
Security assessment
The changes are editorial improvements (e.g., 'is easier' to 'it easier', 'needs' to 'needs'). No security-related content was added or modified. These are general documentation clarifications.
Diff
diff --git a/eks/latest/userguide/kubernetes-concepts.md b/eks/latest/userguide/kubernetes-concepts.md index 78fc52283..4ed2c0c88 100644 --- a//eks/latest/userguide/kubernetes-concepts.md +++ b//eks/latest/userguide/kubernetes-concepts.md @@ -252 +252 @@ The method you would choose for deploying Pods depends on the type of applicatio - * **Stateless applications** — A stateless application doesn’t save a client’s session data, so another session doesn’t need to refer back to what happened to a previous session. This makes is easier to just replace Pods with new ones if they become unhealthy or move them around without saving state. If you are running a stateless application (such as a web server), you can use a [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) to deploy [Pods](https://kubernetes.io/docs/concepts/workloads/pods/)and [ReplicaSets](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/). A ReplicaSet defines how many instances of a Pod that you want running concurrently. Although you can run a ReplicaSet directly, it is common to run replicas directly within a Deployment, to define how many replicas of a Pod should be running at a time. + * **Stateless applications** — A stateless application doesn’t save a client’s session data, so another session doesn’t need to refer back to what happened to a previous session. This makes it easier to just replace Pods with new ones if they become unhealthy or move them around without saving state. If you are running a stateless application (such as a web server), you can use a [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) to deploy [Pods](https://kubernetes.io/docs/concepts/workloads/pods/)and [ReplicaSets](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/). A ReplicaSet defines how many instances of a Pod that you want running concurrently. Although you can run a ReplicaSet directly, it is common to run replicas directly within a Deployment, to define how many replicas of a Pod should be running at a time. @@ -267 +267 @@ With applications often deployed as a set of microservices that moved around to - * **Services** — Because a Pod can move around to different nodes and addresses, another Pod that needed to communicate with the first Pod could find it difficult to find where it is. To solve this problem, Kubernetes lets you represent an application as a [Service](https://kubernetes.io/docs/concepts/services-networking/service/). With a Service, you can identify a Pod or set of Pods with a particular name, then indicate what port exposes that application’s service from the Pod and what ports another application could use to contact that service. Another Pod within a cluster can simply request a Service by name and Kubernetes will direct that request to the proper port for an instance of the Pod running that service. + * **Services** — Because a Pod can move around to different nodes and addresses, another Pod that needs to communicate with the first Pod could find it difficult to locate where it is. To solve this problem, Kubernetes lets you represent an application as a [Service](https://kubernetes.io/docs/concepts/services-networking/service/). With a Service, you can identify a Pod or set of Pods with a particular name, then indicate what port exposes that application’s service from the Pod and what ports another application could use to contact that service. Another Pod within a cluster can simply request a Service by name and Kubernetes will direct that request to the proper port for an instance of the Pod running that service.