Skip to content

Commit

Permalink
docs: Removing and updating broken links on docs/addons (#381)
Browse files Browse the repository at this point in the history
  • Loading branch information
rodrigobersa authored Mar 27, 2024
1 parent 089e81a commit 7755fb6
Show file tree
Hide file tree
Showing 10 changed files with 18 additions and 20 deletions.
5 changes: 2 additions & 3 deletions docs/addons/aws-cloudwatch-metrics.md
Original file line number Diff line number Diff line change
@@ -1,20 +1,19 @@
# AWS CloudWatch Metrics

Use CloudWatch Container Insights to collect, aggregate, and summarize metrics and logs from your containerized applications and microservices. CloudWatch automatically collects metrics for many resources, such as CPU, memory, disk, and network. Container Insights also provides diagnostic information, such as container restart failures, to help you isolate issues and resolve them quickly. You can also set CloudWatch alarms on metrics that Container Insights collects.
Use [AWS CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) to collect, aggregate, and summarize metrics and logs from your containerized applications and microservices. CloudWatch automatically collects metrics for many resources, such as CPU, memory, disk, and network. Container Insights also provides diagnostic information, such as container restart failures, to help you isolate issues and resolve them quickly. You can also set CloudWatch alarms on metrics that Container Insights collects.

Container Insights collects data as performance log events using embedded metric format. These performance log events are entries that use a structured JSON schema that enables high-cardinality data to be ingested and stored at scale. From this data, CloudWatch creates aggregated metrics at the cluster, node, pod, task, and service level as CloudWatch metrics. The metrics that Container Insights collects are available in CloudWatch automatic dashboards, and also viewable in the Metrics section of the CloudWatch console.

## Usage

[aws-cloudwatch-metrics](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/modules/kubernetes-addons/aws-cloudwatch-metrics) can be deployed by enabling the add-on via the following.
AWS CloudWatch Metrics can be deployed by enabling the add-on via the following.

```hcl
enable_aws_cloudwatch_metrics = true
```

You can also customize the Helm chart that deploys `aws-cloudwatch-metrics` via the following configuration:


```hcl
enable_aws_cloudwatch_metrics = true
Expand Down
2 changes: 1 addition & 1 deletion docs/addons/aws-efs-csi-driver.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ This add-on deploys the [AWS EFS CSI driver](https://docs.aws.amazon.com/eks/lat

## Usage

The [AWS EFS CSI driver](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/modules/kubernetes-addons/aws-efs-csi-driver) can be deployed by enabling the add-on via the following. Check out the full [example](https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/examples/stateful/main.tf) to deploy an EKS Cluster with EFS backing the dynamic provisioning of persistent volumes.
The AWS EFS CSI driver can be deployed by enabling the add-on via the following. Check out the full [example](https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/examples/stateful/main.tf) to deploy an EKS Cluster with EFS backing the dynamic provisioning of persistent volumes.

```hcl
enable_aws_efs_csi_driver = true
Expand Down
9 changes: 4 additions & 5 deletions docs/addons/aws-for-fluentbit.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# AWS for Fluent Bit

AWS provides a Fluent Bit image with plugins for both CloudWatch Logs and Kinesis Data Firehose. We recommend using Fluent Bit as your log router because it has a lower resource utilization rate than Fluentd.
AWS provides a [Fluent Bit](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html) image with plugins for both CloudWatch Logs and Kinesis Data Firehose. We recommend using Fluent Bit as your log router because it has a lower resource utilization rate than Fluentd.

## Usage

Expand Down Expand Up @@ -73,22 +73,21 @@ aws-for-fluent-bit-sbn9b 1/1 Running 0 15m
aws-for-fluent-bit-svhwq 1/1 Running 0 15m
```

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/

Open the [CloudWatch console](https://console.aws.amazon.com/cloudwatch/)

In the navigation pane, choose Log groups.

Make sure that you're in the Region where you deployed Fluent Bit.

Check the list of log groups in the Region. You should see the following:

```
```sh
/aws/eks/complete/aws-fluentbit-logs
```

If you enabled Container Insights, you should also see the following Log Groups in your CloudWatch Console.

```
```sh
/aws/containerinsights/Cluster_Name/application

/aws/containerinsights/Cluster_Name/host
Expand Down
4 changes: 2 additions & 2 deletions docs/addons/aws-fsx-csi-driver.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ This add-on deploys the [Amazon FSx CSI Driver](https://docs.aws.amazon.com/eks/

## Usage

The [Amazon FSx CSI Driver](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/modules/kubernetes-addons/aws-fsx-csi-driver) can be deployed by enabling the add-on via the following.
The Amazon FSx CSI Driver can be deployed by enabling the add-on via the following.

```hcl
enable_aws_fsx_csi_driver = true
Expand Down Expand Up @@ -63,7 +63,7 @@ metadata:
name: fsx-sc
provisioner: fsx.csi.aws.com
parameters:
subnetId: <YOUR_SUBNET_IDs>
subnetId: <YOUR_SUBNET_IDs>
securityGroupIds: <YOUR_SG_ID>
perUnitStorageThroughput: "200"
deploymentType: PERSISTENT_1
Expand Down
7 changes: 3 additions & 4 deletions docs/addons/aws-load-balancer-controller.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,11 @@
# AWS Load Balancer Controller.
# AWS Load Balancer Controller

[AWS Load Balancer Controller ](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) is a controller to help manage Elastic Load Balancers for a Kubernetes cluster. This Add-on deploys this controller in an Amazon EKS Cluster.
[AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) is a controller to help manage Elastic Load Balancers for a Kubernetes cluster. This Add-on deploys this controller in an Amazon EKS Cluster.

## Usage

In order to deploy the AWS Load Balancer Controller Addon via [EKS Blueprints Addons](https://github.com/aws-ia/terraform-aws-eks-blueprints-addons), reference the following parameters under the `module.eks_blueprints_addons`.


> **_NOTE_**: In versions 2.5 and newer, the AWS Load Balancer Controller becomes the default controller for Kubernetes service resources with the type: LoadBalancer and makes an AWS Network Load Balancer (NLB) for each service. It does this by making a mutating webhook for services, which sets the spec.loadBalancerClass field to service.k8s.aws/nlb for new services of type: LoadBalancer. You can turn off this feature and revert to using the legacy Cloud Provider as the default controller, by setting the helm chart value enableServiceMutatorWebhook to false. The cluster won't provision new Classic Load Balancers for your services unless you turn off this feature. Existing Classic Load Balancers will continue to work.
```hcl
Expand All @@ -30,6 +29,7 @@ module "eks_blueprints_addons" {
]
}
```

### Helm Chart customization

It's possible to customize your deployment using the Helm Chart parameters inside the `aws_load_balancer_controller` configuration block:
Expand Down Expand Up @@ -60,7 +60,6 @@ It's possible to customize your deployment using the Helm Chart parameters insid

You can find all available Helm Chart parameter values [here](https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/main/helm/aws-load-balancer-controller/values.yaml).


## Validate

1. To validate the deployment, check if the `aws-load-balancer-controller` Pods were created in the `kube-system` Namespace, as the following example.
Expand Down
4 changes: 2 additions & 2 deletions docs/addons/cert-manager.md
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ NAME READY STATUS AGE
selfsigned-cluster-issuer True 3m
```

2. Create a Certificate in a given Namespace.
3. Create a Certificate in a given Namespace.

```yaml
apiVersion: cert-manager.io/v1
Expand All @@ -77,7 +77,7 @@ spec:
group: cert-manager.io
```
3. Check the `certificate` status in it should be in `Ready` state, and be pointing to a `secret` created in the same Namespace.
4. Check the `certificate` status in it should be in `Ready` state, and be pointing to a `secret` created in the same Namespace.

```sh
kubectl get certificate -o wide
Expand Down
2 changes: 1 addition & 1 deletion docs/addons/external-dns.md
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,6 @@ To further configure external-dns, refer to the examples:

* [AWS Load Balancer Controller](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/aws-load-balancer-controller.md)
* [Route53](docs/tutorials/aws.md)
* [Same domain for public and private Route53 zones](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/public-private-route53.md)
* [Same domain for public and private Route53 zones](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/public-private-route53.md)
* [Cloud Map](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/aws-sd.md)
* [Kube Ingress AWS Controller](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/kube-ingress-aws.md)
1 change: 1 addition & 0 deletions docs/addons/fargate-fluentbit.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,6 +26,7 @@ It's possible to customize the CloudWatch Log Group parameters in the `fargate_f
retention_in_days = 7
kms_key_id = "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
skip_destroy = true
}
```

## Validation
Expand Down
3 changes: 1 addition & 2 deletions docs/addons/velero.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@

## Usage

[Velero](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/modules/kubernetes-addons/velero) can be deployed by enabling the add-on via the following.
Velero can be deployed by enabling the add-on via the following.

```hcl
enable_velero = true
Expand Down Expand Up @@ -36,7 +36,6 @@ To see a working example, see the [`stateful`](https://github.com/aws-ia/terrafo

## Validate


1. Run `update-kubeconfig` command:

```bash
Expand Down
1 change: 1 addition & 0 deletions docs/addons/vertical-pod-autoscaler.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
# Vertical Pod Autoscaler

[VPA](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) Vertical Pod Autoscaler (VPA) automatically adjusts the CPU and memory reservations for your pods to help "right size" your applications. When configured, it will automatically request the necessary reservations based on usage and thus allow proper scheduling onto nodes so that the appropriate resource amount is available for each pod. It will also maintain ratios between limits and requests that were specified in initial container configuration.

NOTE: Metrics Server add-on is a dependency for this addon
Expand Down

0 comments on commit 7755fb6

Please sign in to comment.