Update the /docs of the website

website/content/en/docs/concepts/metrics.md

@@ -8,6 +8,48 @@ description: >
 ---
 <!-- this document is generated from hack/docs/metrics_gen_docs.go -->
 Karpenter makes several metrics available in Prometheus format to allow monitoring cluster provisioning status. These metrics are available by default at `karpenter.karpenter.svc.cluster.local:8000/metrics` configurable via the `METRICS_PORT` environment variable documented [here](../settings)
+## Controller Runtime Metrics
+
+### `controller_runtime_active_workers`
+Number of currently used workers per controller
+
+### `controller_runtime_max_concurrent_reconciles`
+Maximum number of concurrent reconciles per controller
+
+### `controller_runtime_reconcile_errors_total`
+Total number of reconciliation errors per controller
+
+### `controller_runtime_reconcile_time_seconds`
+Length of time per reconciliation per controller
+
+### `controller_runtime_reconcile_total`
+Total number of reconciliations per controller
+
+## Consistency Metrics
+
+### `karpenter_consistency_errors`
+Number of consistency checks that have failed.
+
+## Deprovisioning Metrics
+
+### `karpenter_deprovisioning_actions_performed`
+Number of deprovisioning actions performed. Labeled by deprovisioner.
+
+### `karpenter_deprovisioning_consolidation_timeouts`
+Number of times the Consolidation algorithm has reached a timeout. Labeled by consolidation type.
+
+### `karpenter_deprovisioning_eligible_machines`
+Number of machines eligible for deprovisioning by Karpenter. Labeled by deprovisioner
+
+### `karpenter_deprovisioning_evaluation_duration_seconds`
+Duration of the deprovisioning evaluation process in seconds.
+
+### `karpenter_deprovisioning_replacement_machine_initialized_seconds`
+Amount of time required for a replacement machine to become initialized.
+
+### `karpenter_deprovisioning_replacement_machine_launch_failure_counter`
+The number of times that Karpenter failed to launch a replacement node for deprovisioning. Labeled by deprovisioner.
+
 ## Interruption Metrics
 
 ### `karpenter_interruption_actions_performed`
@@ -22,8 +64,94 @@ Length of time between message creation in queue and an action taken on the mess
 ### `karpenter_interruption_received_messages`
 Count of messages received from the SQS queue. Broken down by message type and whether the message was actionable.
 
+## Machines Metrics
+
+### `karpenter_machines_created`
+Number of machines created in total by Karpenter. Labeled by reason the machine was created and the owning provisioner.
+
+### `karpenter_machines_disrupted`
+Number of machines disrupted in total by Karpenter. Labeled by disruption type of the machine and the owning provisioner.
+
+### `karpenter_machines_drifted`
+Number of machine drifted reasons in total by Karpenter. Labeled by drift type of the machine and the owning provisioner..
+
+### `karpenter_machines_initialized`
+Number of machines initialized in total by Karpenter. Labeled by the owning provisioner.
+
+### `karpenter_machines_launched`
+Number of machines launched in total by Karpenter. Labeled by the owning provisioner.
+
+### `karpenter_machines_registered`
+Number of machines registered in total by Karpenter. Labeled by the owning provisioner.
+
+### `karpenter_machines_terminated`
+Number of machines terminated in total by Karpenter. Labeled by reason the machine was terminated and the owning provisioner.
+
+## Provisioner Metrics
+
+### `karpenter_provisioner_limit`
+The Provisioner Limits are the limits specified on the provisioner that restrict the quantity of resources provisioned. Labeled by provisioner name and resource type.
+
+### `karpenter_provisioner_scheduling_duration_seconds`
+Duration of scheduling process in seconds.
+
+### `karpenter_provisioner_scheduling_simulation_duration_seconds`
+Duration of scheduling simulations used for deprovisioning and provisioning in seconds.
+
+### `karpenter_provisioner_usage`
+The Provisioner Usage is the amount of resources that have been provisioned by a particular provisioner. Labeled by provisioner name and resource type.
+
+### `karpenter_provisioner_usage_pct`
+The Provisioner Usage Percentage is the percentage of each resource used based on the resources provisioned and the limits that have been configured in the range [0,100].  Labeled by provisioner name and resource type.
+
+## Nodes Metrics
+
+### `karpenter_nodes_allocatable`
+Node allocatable are the resources allocatable by nodes.
+
+### `karpenter_nodes_created`
+Number of nodes created in total by Karpenter. Labeled by owning provisioner.
+
+### `karpenter_nodes_leases_deleted`
+Number of deleted leaked leases.
+
+### `karpenter_nodes_system_overhead`
+Node system daemon overhead are the resources reserved for system overhead, the difference between the node's capacity and allocatable values are reported by the status.
+
+### `karpenter_nodes_terminated`
+Number of nodes terminated in total by Karpenter. Labeled by owning provisioner.
+
+### `karpenter_nodes_termination_time_seconds`
+The time taken between a node's deletion request and the removal of its finalizer
+
+### `karpenter_nodes_total_daemon_limits`
+Node total daemon limits are the resources specified by DaemonSet pod limits.
+
+### `karpenter_nodes_total_daemon_requests`
+Node total daemon requests are the resource requested by DaemonSet pods bound to nodes.
+
+### `karpenter_nodes_total_pod_limits`
+Node total pod limits are the resources specified by non-DaemonSet pod limits.
+
+### `karpenter_nodes_total_pod_requests`
+Node total pod requests are the resources requested by non-DaemonSet pods bound to nodes.
+
+## Pods Metrics
+
+### `karpenter_pods_startup_time_seconds`
+The time from pod creation until the pod is running.
+
+### `karpenter_pods_state`
+Pod state is the current state of pods. This metric can be used several ways as it is labeled by the pod name, namespace, owner, node, provisioner name, zone, architecture, capacity type, instance type and pod phase.
+
 ## Cloudprovider Metrics
 
+### `karpenter_cloudprovider_duration_seconds`
+Duration of cloud provider method calls. Labeled by the controller, method name and provider.
+
+### `karpenter_cloudprovider_errors_total`
+Total number of errors returned from CloudProvider calls.
+
 ### `karpenter_cloudprovider_instance_type_cpu_cores`
 VCPUs cores for a given instance type.
 

website/content/en/docs/upgrade-guide.md

@@ -15,9 +15,9 @@ To make upgrading easier we aim to minimize introduction of breaking changes wit
 
 [comment]: <> (the content below is generated from hack/docs/compataiblitymetrix_gen_docs.go)
 
-| KUBERNETES |  1.24   |  1.25   |  1.26   |  1.27   |  1.28  |
-|------------|---------|---------|---------|---------|--------|
-| karpenter  | 0.21.x+ | 0.25.x+ | 0.28.x+ | 0.28.x+ | 0.31.0 |
+| KUBERNETES |  1.23   |  1.24   |  1.25   |  1.26   |  1.27   |  1.28  |
+|------------|---------|---------|---------|---------|---------|--------|
+| karpenter  | 0.21.x+ | 0.21.x+ | 0.25.x+ | 0.28.x+ | 0.28.x+ | 0.31.x |
 
 [comment]: <> (end docs generated content from hack/docs/compataiblitymetrix_gen_docs.go)
 
@@ -69,9 +69,9 @@ If you get the error `invalid ownership metadata; label validation error:` while
 In general, you can reapply the CRDs in the `crds` directory of the Karpenter helm chart:
 
 ```shell
-kubectl apply -f https://raw.githubusercontent.com/aws/karpenter/v0.31.0/pkg/apis/crds/karpenter.sh_provisioners.yaml
-kubectl apply -f https://raw.githubusercontent.com/aws/karpenter/v0.31.0/pkg/apis/crds/karpenter.sh_machines.yaml
-kubectl apply -f https://raw.githubusercontent.com/aws/karpenter/v0.31.0/pkg/apis/crds/karpenter.k8s.aws_awsnodetemplates.yaml
+kubectl apply -f https://raw.githubusercontent.com/aws/karpenter/docs/pkg/apis/crds/karpenter.sh_provisioners.yaml
+kubectl apply -f https://raw.githubusercontent.com/aws/karpenter/docs/pkg/apis/crds/karpenter.sh_machines.yaml
+kubectl apply -f https://raw.githubusercontent.com/aws/karpenter/docs/pkg/apis/crds/karpenter.k8s.aws_awsnodetemplates.yaml
 ```
 
 ### How Do We Break Incompatibility?
@@ -232,7 +232,7 @@ kubectl delete mutatingwebhookconfigurations defaulting.webhook.karpenter.sh
 * The karpenter webhook and controller containers are combined into a single binary, which requires changes to the helm chart. If your Karpenter installation (helm or otherwise) currently customizes the karpenter webhook, your deployment tooling may require minor changes.
 * Karpenter now supports native interruption handling. If you were previously using Node Termination Handler for spot interruption handling and health events, you will need to remove the component from your cluster before enabling `aws.interruptionQueueName`. For more details on Karpenter's interruption handling, see the [Interruption Handling Docs]({{< ref "./concepts/deprovisioning/#interruption" >}}). For common questions on the migration process, see the [FAQ]({{< ref "./faq/#interruption-handling" >}})
 * Instance category defaults are now explicitly persisted in the Provisioner, rather than handled implicitly in memory. By default, Provisioners will limit instance category to c,m,r. If any instance type constraints are applied, it will override this default. If you have created Provisioners in the past with unconstrained instance type, family, or category, Karpenter will now more flexibly use instance types than before. If you would like to apply these constraints, they must be included in the Provisioner CRD.
-* Karpenter CRD raw YAML URLs have migrated from `https://raw.githubusercontent.com/aws/karpenter/v0.31.0/charts/karpenter/crds/...` to `https://raw.githubusercontent.com/aws/karpenter/v0.31.0/pkg/apis/crds/...`. If you reference static Karpenter CRDs or rely on `kubectl replace -f` to apply these CRDs from their remote location, you will need to migrate to the new location.
+* Karpenter CRD raw YAML URLs have migrated from `https://raw.githubusercontent.com/aws/karpenter/preivew/charts/karpenter/crds/...` to `https://raw.githubusercontent.com/aws/karpenter/preview/pkg/apis/crds/...`. If you reference static Karpenter CRDs or rely on `kubectl replace -f` to apply these CRDs from their remote location, you will need to migrate to the new location.
 * Pods without an ownerRef (also called "controllerless" or "naked" pods) will now be evicted by default during node termination and consolidation.  Users can prevent controllerless pods from being voluntarily disrupted by applying the `karpenter.sh/do-not-evict: "true"` annotation to the pods in question.
 * The following CLI options/environment variables are now removed and replaced in favor of pulling settings dynamically from the [`karpenter-global-settings`]({{<ref "./concepts/settings#configmap" >}}) ConfigMap. See the [Settings docs]({{<ref "./concepts/settings/#environment-variables--cli-flags" >}}) for more details on configuring the new values in the ConfigMap.
 

website/content/en/preview/concepts/threat-model.md

@@ -31,11 +31,11 @@ A Cluster Developer has the ability to create pods via Deployments, ReplicaSets,
 
 Karpenter has permissions to create and manage cloud instances. Karpenter has Kubernetes API permissions to create, update, and remove nodes, as well as evict pods. For a full list of the permissions, see the RBAC rules in the helm chart template. Karpenter also has AWS IAM permissions to create instances with IAM roles.
 
-* [aggregate-clusterrole.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/aggregate-clusterrole.yaml)
-* [clusterrole-core.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/clusterrole-core.yaml)
-* [clusterrole.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/clusterrole.yaml)
-* [rolebinding.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/rolebinding.yaml)
-* [role.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/role.yaml)
+* [aggregate-clusterrole.yaml](https://github.com/aws/karpenter/blob/preview/charts/karpenter/templates/aggregate-clusterrole.yaml)
+* [clusterrole-core.yaml](https://github.com/aws/karpenter/blob/preview/charts/karpenter/templates/clusterrole-core.yaml)
+* [clusterrole.yaml](https://github.com/aws/karpenter/blob/preview/charts/karpenter/templates/clusterrole.yaml)
+* [rolebinding.yaml](https://github.com/aws/karpenter/blob/preview/charts/karpenter/templates/rolebinding.yaml)
+* [role.yaml](https://github.com/aws/karpenter/blob/preview/charts/karpenter/templates/role.yaml)
 
 ## Assumptions
 

website/content/en/preview/faq.md

@@ -15,7 +15,7 @@ AWS is the first cloud provider supported by Karpenter, although it is designed
 
 ### Can I write my own cloud provider for Karpenter?
 Yes, but there is no documentation yet for it.
-Start with Karpenter's GitHub [cloudprovider](https://github.com/aws/karpenter-core/tree{{< githubRelRef >}}pkg/cloudprovider) documentation to see how the AWS provider is built, but there are other sections of the code that will require changes too.
+Start with Karpenter's GitHub [cloudprovider](https://github.com/aws/karpenter-core/tree/preview/pkg/cloudprovider) documentation to see how the AWS provider is built, but there are other sections of the code that will require changes too.
 
 ### What operating system nodes does Karpenter deploy?
 By default, Karpenter uses Amazon Linux 2 images.
@@ -28,7 +28,7 @@ Karpenter is flexible to multi architecture configurations using [well known lab
 
 ### What RBAC access is required?
 All of the required RBAC rules can be found in the helm chart template.
-See [clusterrolebinding.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/clusterrolebinding.yaml), [clusterrole.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/clusterrole.yaml), [rolebinding.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/rolebinding.yaml), and [role.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/role.yaml) files for details.
+See [clusterrolebinding.yaml](https://github.com/aws/karpenter/blob/preview/charts/karpenter/templates/clusterrolebinding.yaml), [clusterrole.yaml](https://github.com/aws/karpenter/blob/preview/charts/karpenter/templates/clusterrole.yaml), [rolebinding.yaml](https://github.com/aws/karpenter/blob/preview/charts/karpenter/templates/rolebinding.yaml), and [role.yaml](https://github.com/aws/karpenter/blob/preview/charts/karpenter/templates/role.yaml) files for details.
 
 ### Can I run Karpenter outside of a Kubernetes cluster?
 Yes, as long as the controller has network and IAM/RBAC access to the Kubernetes API and your provider API.

website/content/en/preview/getting-started/migrating-from-cas/_index.md

@@ -134,7 +134,7 @@ Now that our deployment is ready we can create the karpenter namespace, create t
 ## Create default provisioner
 
 We need to create a default provisioner so Karpenter knows what types of nodes we want for unscheduled workloads.
-You can refer to some of the [example provisioners](https://github.com/aws/karpenter/tree{{< githubRelRef >}}examples/provisioner) for specific needs.
+You can refer to some of the [example provisioners](https://github.com/aws/karpenter/tree/preview/examples/provisioner) for specific needs.
 
 {{% script file="./content/en/{VERSION}/getting-started/migrating-from-cas/scripts/step11-create-provisioner.sh" language="bash" %}}
 

website/content/en/preview/upgrade-guide.md

@@ -69,9 +69,9 @@ If you get the error `invalid ownership metadata; label validation error:` while
 In general, you can reapply the CRDs in the `crds` directory of the Karpenter helm chart:
 
 ```shell
-kubectl apply -f https://raw.githubusercontent.com/aws/karpenter{{< githubRelRef >}}pkg/apis/crds/karpenter.sh_provisioners.yaml
-kubectl apply -f https://raw.githubusercontent.com/aws/karpenter{{< githubRelRef >}}pkg/apis/crds/karpenter.sh_machines.yaml
-kubectl apply -f https://raw.githubusercontent.com/aws/karpenter{{< githubRelRef >}}pkg/apis/crds/karpenter.k8s.aws_awsnodetemplates.yaml
+kubectl apply -f https://raw.githubusercontent.com/aws/karpenter/preview/pkg/apis/crds/karpenter.sh_provisioners.yaml
+kubectl apply -f https://raw.githubusercontent.com/aws/karpenter/preview/pkg/apis/crds/karpenter.sh_machines.yaml
+kubectl apply -f https://raw.githubusercontent.com/aws/karpenter/perview/pkg/apis/crds/karpenter.k8s.aws_awsnodetemplates.yaml
 ```
 
 ### How Do We Break Incompatibility?
@@ -232,7 +232,7 @@ kubectl delete mutatingwebhookconfigurations defaulting.webhook.karpenter.sh
 * The karpenter webhook and controller containers are combined into a single binary, which requires changes to the helm chart. If your Karpenter installation (helm or otherwise) currently customizes the karpenter webhook, your deployment tooling may require minor changes.
 * Karpenter now supports native interruption handling. If you were previously using Node Termination Handler for spot interruption handling and health events, you will need to remove the component from your cluster before enabling `aws.interruptionQueueName`. For more details on Karpenter's interruption handling, see the [Interruption Handling Docs]({{< ref "./concepts/deprovisioning/#interruption" >}}). For common questions on the migration process, see the [FAQ]({{< ref "./faq/#interruption-handling" >}})
 * Instance category defaults are now explicitly persisted in the Provisioner, rather than handled implicitly in memory. By default, Provisioners will limit instance category to c,m,r. If any instance type constraints are applied, it will override this default. If you have created Provisioners in the past with unconstrained instance type, family, or category, Karpenter will now more flexibly use instance types than before. If you would like to apply these constraints, they must be included in the Provisioner CRD.
-* Karpenter CRD raw YAML URLs have migrated from `https://raw.githubusercontent.com/aws/karpenter{{< githubRelRef >}}charts/karpenter/crds/...` to `https://raw.githubusercontent.com/aws/karpenter{{< githubRelRef >}}pkg/apis/crds/...`. If you reference static Karpenter CRDs or rely on `kubectl replace -f` to apply these CRDs from their remote location, you will need to migrate to the new location.
+* Karpenter CRD raw YAML URLs have migrated from `https://raw.githubusercontent.com/aws/karpenter/preview/charts/karpenter/crds/...` to `https://raw.githubusercontent.com/aws/karpenter/preview/pkg/apis/crds/...`. If you reference static Karpenter CRDs or rely on `kubectl replace -f` to apply these CRDs from their remote location, you will need to migrate to the new location.
 * Pods without an ownerRef (also called "controllerless" or "naked" pods) will now be evicted by default during node termination and consolidation.  Users can prevent controllerless pods from being voluntarily disrupted by applying the `karpenter.sh/do-not-evict: "true"` annotation to the pods in question.
 * The following CLI options/environment variables are now removed and replaced in favor of pulling settings dynamically from the [`karpenter-global-settings`]({{<ref "./concepts/settings#configmap" >}}) ConfigMap. See the [Settings docs]({{<ref "./concepts/settings/#environment-variables--cli-flags" >}}) for more details on configuring the new values in the ConfigMap.