Skip to content
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.

Sign up for GitHub

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

Change operator to admin #1137

Merged
merged 6 commits into from
Jan 13, 2022
Merged

Change operator to admin #1137

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
287d693
Change provision pod to schedule pod in docs
chrisnegus Jan 6, 2022
1eac73b
Merge branch 'aws:main' into main
Jan 7, 2022
860a0fd
Merge branch 'aws:main' into main
Jan 9, 2022
872a24b
Merge branch 'aws:main' into main
Jan 13, 2022
aaf93d0
Changing cluster operator to cluster administrator in docs
chrisnegus Jan 13, 2022
0e7d010
Small fix
chrisnegus Jan 13, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions website/content/en/docs/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,9 +19,9 @@ Karpenter works by:
* **Scheduling** the pods to run on the new nodes
* **Removing** the nodes when the nodes are no longer needed

As a cluster operator, you can configure an unconstrained Karpenter provisioner when it is first installed and not change it again.
As a cluster administrator, you can configure an unconstrained Karpenter provisioner when it is first installed and not change it again.
Other times, you might continue to tweak the provisioner or create multiple provisioners for a cluster used by different teams.
On-going cluster operator tasks include upgrading and decommissioning nodes.
On-going cluster administrator tasks include upgrading and decommissioning nodes.

As an application developer, you can make specific requests for capacity and features you want from the nodes running your pods.
Karpenter is designed to quickly create the best possible nodes to meet those needs and schedule the pods to run on them.
Expand Down
8 changes: 4 additions & 4 deletions website/content/en/docs/concepts/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,12 +4,12 @@ linkTitle: "Concepts"
weight: 35
---

Users fall under two basic roles: Kubernetes cluster operators and application developers.
Users fall under two basic roles: Kubernetes cluster administrators and application developers.
This document describes Karpenter concepts through the lens of those two types of users.

## Cluster operator
## Cluster administrator

As a Kubernetes cluster operator, you can engage with Karpenter to:
As a Kubernetes cluster administrator, you can engage with Karpenter to:

* Install Karpenter
* Configure provisioners to set constraints and other features for managing nodes
Expand Down Expand Up @@ -82,7 +82,7 @@ The concept of layered constraints is key to using Karpenter.
With no constraints defined in provisioners and none requested from pods being deployed, Karpenter chooses from the entire universe of features available to your cloud provider.
Nodes can be created using any instance type and run in any zones.

An application developer can tighten the constraints defined in a provisioner by the cluster operator by defining additional scheduling constraints in their pod spec.
An application developer can tighten the constraints defined in a provisioner by the cluster administrator by defining additional scheduling constraints in their pod spec.
Refer to the description of Karpenter constraints in the Application Developer section below for details.

### Scheduling
Expand Down
2 changes: 1 addition & 1 deletion website/content/en/docs/tasks/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,4 +4,4 @@ linkTitle: "Tasks"
weight: 45
---

Karpenter tasks can be divided into those for a cluster operator who is managing the cluster itself and application developers who are deploying pod workloads on a cluster.
Karpenter tasks can be divided into those for a cluster administrator who is managing the cluster itself and application developers who are deploying pod workloads on a cluster.
2 changes: 1 addition & 1 deletion website/content/en/docs/tasks/running-pods.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ Reasons for constraining where your pods run could include:
* Wanting to use techniques like topology spread to help insure high availability

Your Cloud Provider defines the first layer of constraints, including all instance types, architectures, zones, and purchase types available to its cloud.
The cluster operator adds the next layer of constraints by creating one or more provisioners.
The cluster administrator adds the next layer of constraints by creating one or more provisioners.
The final layer comes from you adding specifications to your Kubernetes pod deployments.
Pod scheduling constraints must fall within a provisioner's constraints or the pods will not deploy.
For example, if the provisioner sets limits that allow only a particular zone to be used, and a pod asks for a different zone, it will not be scheduled.
Expand Down