diff --git a/website/docs/observability/resource-view/addon_view.md b/website/docs/observability/resource-view/addon_view.md new file mode 100644 index 000000000..417d01315 --- /dev/null +++ b/website/docs/observability/resource-view/addon_view.md @@ -0,0 +1,18 @@ +--- +title: "Add-ons" +sidebar_position: 20 +--- + +EKS add-ons allows you to configure, deploy, and update the operational software, or add-ons, that provide key functionality to support your Kubernetes applications. These add-ons include critical tools for cluster networking like the Amazon VPC CNI, as well as operational software for observability, management, scaling, and security. An add-on is basically a software that provides supporting operational capabilities to Kubernetes applications, but is not specific to the application. + +**[Amazon EKS add-ons](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html)** provide installation and management of a curated set of add-ons for Amazon EKS clusters. All Amazon EKS add-ons include the latest security patches, bug fixes, and are validated by AWS to work with Amazon EKS. Amazon EKS add-ons allow you to consistently ensure that your Amazon EKS clusters are secure and stable and reduce the amount of work that you need to do in order to install, configure, and update add-ons. + +You can add, update, or delete Amazon EKS add-ons using the Amazon EKS API, AWS Management Console, AWS CLI, and eksctl. You can also [create Amazon EKS add-ons](https://aws-ia.github.io/terraform-aws-eks-blueprints-addons/main/amazon-eks-addons/) , The Amazon EKS add-on implementation is generic and can be used to deploy any add-on supported by the EKS API; either native EKS addons or third party add-ons supplied via the AWS Marketplace. + +If you navigate to the **Add-ons** tab you can search for add-ons already installed. + +![Insights](/img/resource-view/find-add-ons.jpg) + +or 'Get more add-ons' to choose additional add-ons or search AWS MarketPlace add-ons to enhance your cluster. + +![Insights](/img/resource-view/select-add-ons.jpg) diff --git a/website/docs/observability/resource-view/authentication/index.md b/website/docs/observability/resource-view/authentication/index.md deleted file mode 100644 index 9c1fb0a56..000000000 --- a/website/docs/observability/resource-view/authentication/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "Authentication" -sidebar_position: 100 ---- - -Click on the Authentication tab to drill down to the ServiceAccounts section and you can view Kubernetes service account resources by namespace. - -:::info -Check out the [Security](../../../security/) module for additional examples. -:::Authentication examples. - -![Insights](/img/resource-view/auth-resources.jpg) diff --git a/website/docs/observability/resource-view/authentication/service-accounts.md b/website/docs/observability/resource-view/authentication/service-accounts.md deleted file mode 100644 index fe64c27c6..000000000 --- a/website/docs/observability/resource-view/authentication/service-accounts.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "ServiceAccounts" -sidebar_position: 40 ---- - -A [ServiceAccount](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) provides an identity for processes that run in a Pod. When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace. For example you can see the spec.serviceAccountName field has been automatically set in the [pod view](../workloads-view/pods_view) - -![Insights](/img/resource-view/auth-resources.jpg) - -To view additional details for a specific service account, drill down to the namespace and click on the service account you want to view to see additional information such as labels, annotations, events. Below is the detail view for the catalog service account. - -![Insights](/img/resource-view/auth-sa-detail.jpg) diff --git a/website/docs/observability/resource-view/authorization/index.md b/website/docs/observability/resource-view/authorization/index.md deleted file mode 100644 index 14fdf6262..000000000 --- a/website/docs/observability/resource-view/authorization/index.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: "Authorization" -sidebar_position: 100 ---- - -In EKS, you must be authenticated (logged in) before your request can be authorized (granted permission to access). Kubernetes expects attributes that are common to REST API requests. This means that EKS authorization works with [AWS Identity and Access Management](https://docs.aws.amazon.com/eks/latest/userguide/security-iam.html) for access control. - -In this lab, we'll view Kubernetes **Role Based Access Control (RBAC)** resources: Cluster Roles, Roles, ClusterRoleBindings and RoleBindings. RBAC is the process of providing restricted least privileged access to EKS clusters and its objects as per the IAM roles mapped to the EKS cluster users. Following diagram depicts how the access control flows when users or service accounts try to access the objects in EKS cluster through the Kubernetes client and API's. - -:::info -Check out the [Security](../../../security/) module for additional examples. -::: - -![Insights](/img/resource-view/autz-index.jpg) diff --git a/website/docs/observability/resource-view/authorization/role-bindings.md b/website/docs/observability/resource-view/authorization/role-bindings.md deleted file mode 100644 index 0375cd428..000000000 --- a/website/docs/observability/resource-view/authorization/role-bindings.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: "RoleBindings" -sidebar_position: 44 ---- - -A **[Role binding](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)** grants role permissions to a user or set of users. Rolebindings are assigned to a particular namespace during creation. The Rolebinding resource holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A **_RoleBinding_** grants permissions within a specific namespace like pods, replicasets, jobs, and deployments. Whereas a **_ClusterRoleBinding_** grants cluster scoped resources like nodes. - -Under Resource Type - Authorization section you can view **_ClusterRoleBindings_** and **_Rolebindings_** resources on your cluster listed by namespace. Example **_RoleBindings_** are shown in the following screenshot. - -![Insights](/img/resource-view/autz-rolebinding.jpg) - -A **[ClusterRoleBinding](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)** attach **_ClusterRoles_** to a set of users. They are scoped to a cluster, and are not bound to namespaces like **_Roles_** and **_RoleBindings_**. - -![Insights](/img/resource-view/authz-crolebinding.jpg) diff --git a/website/docs/observability/resource-view/authorization/roles.md b/website/docs/observability/resource-view/authorization/roles.md deleted file mode 100644 index 7104270c5..000000000 --- a/website/docs/observability/resource-view/authorization/roles.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "Roles" -sidebar_position: 43 ---- - -A **[Role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)** defines a set of permissions to be applied to a user. Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization. A Role always sets permissions within a particular namespace, when you create a Role, you have to specify the namespace it belongs in. - -Under **_Resource Type_** - **_Authorization_** section you can view **_ClusterRoles_** and **_Roles_** resources on your cluster listed by namespace. - -![Insights](/img/resource-view/autz-role.jpg) - -Click on the **_cluster-autoscaler-aws-cluster-autoscaler_** role to view more details for that **_role_**. The below screenshot shows the **_cluster-autoscaler-aws-cluster-autoscaler_** role created under namespace **_kube-system_** which has authorization to **_delete_**, **_get_**, and **_update_** on **_configmaps_** resources. - -![Insights](/img/resource-view/autz-role-detail.jpg) - -A **[ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole)** are a set of rules that are scoped to a cluster and not a namespace, which makes them different from a **_Role_**. **_ClusterRoles_** are additive, and you cannot set "deny" rules. You would generally use **_ClusterRoles_** to define cluster-wide permissions. Below we can see the list of **_ClusterRoles_** on your cluster. - -![Insights](/img/resource-view/authz-crole.jpg) diff --git a/website/docs/observability/resource-view/cluster-view/index.md b/website/docs/observability/resource-view/cluster-view/index.md deleted file mode 100644 index 721091699..000000000 --- a/website/docs/observability/resource-view/cluster-view/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Cluster" -sidebar_position: 60 ---- - -To view the Kubernetes cluster resources, click on the Resources tab. Drill down to the Cluster section and you can view several Kubernetes API resource types that are part of cluster. Cluster view details all the components of the cluster architecture like Nodes, Namespaces and API Services that run the workloads. diff --git a/website/docs/observability/resource-view/cluster-view/namespace_view.md b/website/docs/observability/resource-view/cluster-view/namespace_view.md deleted file mode 100644 index e1ac3164f..000000000 --- a/website/docs/observability/resource-view/cluster-view/namespace_view.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "Namespaces" -sidebar_position: 40 ---- - -[Namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces) are a mechanism to organize clusters which can be very helpful when different teams or projects share a Kubernetes cluster. In our sample application we have microservices - carts, checkout, catalog, assets which all share the same cluster using the namespace construct. - -![Insights](/img/resource-view/cluster-ns.jpg) diff --git a/website/docs/observability/resource-view/cluster-view/nodes_view.md b/website/docs/observability/resource-view/cluster-view/nodes_view.md deleted file mode 100644 index fad3704c5..000000000 --- a/website/docs/observability/resource-view/cluster-view/nodes_view.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Nodes" -sidebar_position: 30 ---- - -Kubernetes runs your workload by placing containers into pods to run on [Nodes](https://kubernetes.io/docs/concepts/architecture/nodes/). A node may be a virtual or physical machine, depending on the cluster. The eks-workshop is running 3 nodes on which the workloads are deployed. Click on the Nodes drill down to list the nodes. - -![Insights](/img/resource-view/cluster-node.jpg) - -If you click on any of the node names, you will find the Info section that has a lot of details of the node - OS, container runtime, instance type, EC2 instance and [Managed node group](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) (that make it easy to provision compute capacity for the cluster). The next section, Capacity allocation shows usage and reservation of various resources on EC2 worker nodes connected to the cluster. - -![Insights](/img/resource-view/cluster-node-detail1.jpg) - -The next section Pods, details all the pods provisioned on the node. In this example, there are 12 running pods on this node. - -![Insights](/img/resource-view/cluster-node-detail2.jpg) - -The next section details any applicable [Taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/), labels and annotations. - -![Insights](/img/resource-view/cluster-node-detail3.jpg) diff --git a/website/docs/observability/resource-view/config-secret-view/index.md b/website/docs/observability/resource-view/config-secret-view/index.md deleted file mode 100644 index 2a8dcece2..000000000 --- a/website/docs/observability/resource-view/config-secret-view/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Config and Secrets" -sidebar_position: 80 ---- - -To view the Kubernetes ConfigMap and Secrets resources, click on the Resources tab. Drill down to the Config and secrets section and you can view several the Kubernetes API resource types that are part of ConfigMap and Secrets API. This lab exercise details resources that Kubernetes provides for configuring workloads with non-confidential data using ConfigMap and sensitive data using Secrets. diff --git a/website/docs/observability/resource-view/config-secret-view/secret_view.md b/website/docs/observability/resource-view/config-secret-view/secret_view.md deleted file mode 100644 index 5c0ad8c49..000000000 --- a/website/docs/observability/resource-view/config-secret-view/secret_view.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: "Secrets" -sidebar_position: 35 ---- - -[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) is a Kubernetes resource object for storing sensitive pieces of data such as username, passwords, tokens, and other credentials. Secrets are helpful to organize and distribute sensitive information across the pods in a cluster. Secrets can be used in a variety of ways, such as being mounted as data volumes or exposed as environment variables to be used by a container in a Pod. - -Click on the Secrets drill down and you can see all the secrets for the cluster. - -![Insights](/img/resource-view/config-secrets.jpg) - -If you click on the Secrets checkout-config you can see the secrets associated with it. In this case, notice the encoded token. You should see the decoded value as well with the decode toggle button. - -![Insights](/img/resource-view/config-secrets-1.jpg) diff --git a/website/docs/observability/resource-view/extensions/custom-resource-definitions.md b/website/docs/observability/resource-view/extensions/custom-resource-definitions.md deleted file mode 100644 index 2b0f82beb..000000000 --- a/website/docs/observability/resource-view/extensions/custom-resource-definitions.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "CustomResourceDefinitions" -sidebar_position: 47 ---- - -**[CustomResourceDefinitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions)** API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource. The name of a CRD object must be a valid **DNS subdomain name**. - -Under **_Resource Types_** - **_Extensions_** you can view a list of the **_Custom Resource Definitions_** on the cluster. - -![Insights](/img/resource-view/ext-crd.jpg) diff --git a/website/docs/observability/resource-view/extensions/index.md b/website/docs/observability/resource-view/extensions/index.md deleted file mode 100644 index dca609e7c..000000000 --- a/website/docs/observability/resource-view/extensions/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Extensions" -sidebar_position: 130 ---- - -[Extensions](https://kubernetes.io/docs/concepts/extend-kubernetes/) are software components that extend and deeply integrate with Kubernetes. In this lab exercise, we'll view common extension resource types including **_Custom Resource Definitions_**, **_Mutating Webhook Configurations_**, and **_Validating Webhook Configurations_** diff --git a/website/docs/observability/resource-view/extensions/webhook-configurations.md b/website/docs/observability/resource-view/extensions/webhook-configurations.md deleted file mode 100644 index 3161f921d..000000000 --- a/website/docs/observability/resource-view/extensions/webhook-configurations.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "Webhook Configurations" -sidebar_position: 48 ---- - -Webhook configurations are executed during the process of intercepting authenticated API request to accept an object request or deny an object by _[Kubernetes Admission controllers](https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/)_. Kubernetes admission controllers sets a security baseline across namespace or cluster. The following diagram describes the different steps involved in the admission controller process. - -![Insights](/img/resource-view/ext-admincontroller.png) - -[Mutating admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) modify objects sent to the API server to enforce custom defaults. - -Under **_Resource Types_** - **_Extensions_** you can view a list of the **_Mutating Webhook Configurations_** on the cluster - -![Insights](/img/resource-view/ext-mutatingwebhook.jpg) - -The below screenshot shows the details of the _aws-load-balancer-webhook_. You can see in this webhook configuration that `Match policy = Equivalent` which means -request will be sent to webhook by modifying the object as per the webhook version `Admission review version = v1beta1`. - -When the configuration `Match policy = Equivalent` then when a new request is processed but has a different webhook version then specified in the configuration, the request will not be sent to webhook. Notice the _Side Effects_ is set to `None` and the _Timeout Seconds_ is set to `10` meaning this webhook has no side effects and will be rejected after 10 seconds. - -![Insights](/img/resource-view/ext-mutatingwebhook-detail.jpg) - -**[Validating admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)** validate requests to the API server. Their configuration includes settings to validate requests. Configurations of **_ValidatingAdmissionWebhooks_** are similar to **_MutatingAdmissionWebhook_**, however the final status of **_ValidatingAdmissionWebhooks_** request objects are stored in etcd. - -![Insights](/img/resource-view/ext-valiatewebhook-detail.jpg) diff --git a/website/docs/observability/resource-view/index.md b/website/docs/observability/resource-view/index.md index a9b733930..4ccc3ac54 100644 --- a/website/docs/observability/resource-view/index.md +++ b/website/docs/observability/resource-view/index.md @@ -1,5 +1,5 @@ --- -title: "View resources in EKS console" +title: "View EKS console" sidebar_position: 20 sidebar_custom_props: { "module": true } description: "Gain visibility of Kubernetes resources in the Amazon Elastic Kubernetes Service console." diff --git a/website/docs/observability/resource-view/observability_view.md b/website/docs/observability/resource-view/observability_view.md new file mode 100644 index 000000000..a5125d7b2 --- /dev/null +++ b/website/docs/observability/resource-view/observability_view.md @@ -0,0 +1,15 @@ +--- +title: "Observability" +sidebar_position: 30 +--- + +Keeping a watchful eye on your applications,network and infrastructure is crucial for ensuring optimal performance, identifying bottlenecks, and troubleshooting issues promptly. +AWS observability lets you collect, correlate, aggregate, and analyze telemetry in your network, infrastructure, and applications so you can gain insights into the behavior, performance, and health of your system. These insights help you detect, investigate, and remediate problems faster. + +Observability tab on the EKS console provides a comprehensive view on the end-to-end observability for EKS clusters. As shown below, use either Prometheus metrics or CloudWatch metrics to collect, and send cluster, infrastructure and application metrics to [Amazon Managed Service for Prometheus](https://aws.amazon.com/prometheus/) . You can use [Amazon Managed Grafana](https://aws.amazon.com/grafana/) to visualize the metrics in dashboard and create alerts. + +Prometheus discovers and collects metrics from the cluster through a pull-based model called scraping. Scrapers are setup to gather data from your cluster infrastructure and containerized applications. Use **Add scraper** to setup a scraper for the cluster. + +You can enable CloudWatch Observability in your clusters through the CloudWatch Observability add-on. Navigate to the add-ons tab and install CloudWatch Observability add-on to enable CloudWatch Application Signals and Container Insights and start ingesting telemetry into CloudWatch. + +![Insights](/img/resource-view/observability-view.jpg) diff --git a/website/docs/observability/resource-view/service-networking-view/index.md b/website/docs/observability/resource-view/service-networking-view/index.md deleted file mode 100644 index ed8dc8d7a..000000000 --- a/website/docs/observability/resource-view/service-networking-view/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Service and Networking" -sidebar_position: 70 ---- - -To view the Kubernetes service and networking resources, click on the Resources tab. Drill down to the Service and Networking section and you can view several the Kubernetes API resource types that are part of service and networking. This lab exercise details ways to expose an application running on a set of Pods as Service, Endpoints and Ingresses. diff --git a/website/docs/observability/resource-view/storage-view/csi_drivers.md b/website/docs/observability/resource-view/storage-view/csi_drivers.md deleted file mode 100644 index 9b897b1c2..000000000 --- a/website/docs/observability/resource-view/storage-view/csi_drivers.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "CSIDrivers" -sidebar_position: 34 ---- - -A [Container Storage Interface (CSI)](https://kubernetes.io/docs/concepts/storage/volumes/#csi) defines a standard interface for Kubernetes to expose arbitrary storage systems to container workloads. - -![Insights](/img/resource-view/storage-csidrivers.png) diff --git a/website/docs/observability/resource-view/storage-view/csi_node.md b/website/docs/observability/resource-view/storage-view/csi_node.md deleted file mode 100644 index c5bedd73b..000000000 --- a/website/docs/observability/resource-view/storage-view/csi_node.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "CSINodes" -sidebar_position: 35 ---- - -Container Storage Interface (CSI) node plugins are needed to perform various privileged operations like scanning of disk devices and mounting of file systems. These operations differ for each host operating system. For Linux worker nodes, containerized CSI node plugins are typically deployed as privileged containers. For Windows worker nodes, privileged operations for containerized CSI node plugins is supported using [csi-proxy](https://github.com/kubernetes-csi/csi-proxy), a community-managed, stand-alone binary that needs to be pre-installed on each Windows node. - -![Insights](/img/resource-view/storage-csinodes.png) - -[CSI Storage capacity](https://kubernetes.io/docs/concepts/storage/storage-capacity/) is limited and may vary depending on the node on which a pod runs: network-attached storage might not be accessible by all nodes, or storage is local to a node to begin with. diff --git a/website/docs/observability/resource-view/storage-view/index.md b/website/docs/observability/resource-view/storage-view/index.md deleted file mode 100644 index 49bfe3e8d..000000000 --- a/website/docs/observability/resource-view/storage-view/index.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: "Storage" -sidebar_position: 90 ---- - -To view the Kubernetes storage resources, click on the Resources tab. Drill down to the Storage section and you can view several the Kubernetes API resource types related to storage that are part of cluster including: - -- Persistent Volume Claims -- Persistent Volumes -- Storage Classes -- Volume Attachments -- CSI Drivers -- CSI Nodes - -The [Storage](../../../fundamentals/storage/) workshop module goes into more details on how to configure and use storage for stateful workloads. diff --git a/website/docs/observability/resource-view/storage-view/persistent-volume-claim.md b/website/docs/observability/resource-view/storage-view/persistent-volume-claim.md deleted file mode 100644 index 59e4473e3..000000000 --- a/website/docs/observability/resource-view/storage-view/persistent-volume-claim.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: "PersistentVolumeClaims" -sidebar_position: 30 ---- - -[PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) (PVC) is a request for storage by a user. This resource is similar to Pods. Pods consume node resources and PVCs consume Persistent Volume (PV) resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany. See [AccessModes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) for more information) - -Click on the PersistentVolumeClaim to drill down all the claims and select the _checkout_ namespace. - -![Insights](/img/resource-view/storage-pvclaim.jpg) - -If you drill down to the namespace _checkout_ you can see the claims and select the respective claims to view the properties associated with it like storage, storage class, and volume mode. - -![Insights](/img/resource-view/storage-pvclaim-detail2.jpg) diff --git a/website/docs/observability/resource-view/storage-view/persistent-volume.md b/website/docs/observability/resource-view/storage-view/persistent-volume.md deleted file mode 100644 index a2d91016b..000000000 --- a/website/docs/observability/resource-view/storage-view/persistent-volume.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "PersistentVolumes" -sidebar_position: 31 ---- - -[PersistentVolume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) A PersistentVolume (PV) is a configured unit of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/). It's a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that EBS, EFS or other third party PV providers. - -![Insights](/img/resource-view/storage-pv.png) diff --git a/website/docs/observability/resource-view/storage-view/storage-classes.md b/website/docs/observability/resource-view/storage-view/storage-classes.md deleted file mode 100644 index 89b87682d..000000000 --- a/website/docs/observability/resource-view/storage-view/storage-classes.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "StorageClasses" -sidebar_position: 32 ---- - -A [StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes/) provides a way for administrators to describe the "classes" of storage that are available to a cluster. Different classes might map to quality-of-service levels, or to backup policies, or to arbitrary policies determined by cluster administrators. - -![Insights](/img/resource-view/storage-storageclasses.png) diff --git a/website/docs/observability/resource-view/storage-view/volume_attachement.md b/website/docs/observability/resource-view/storage-view/volume_attachement.md deleted file mode 100644 index a7d296a31..000000000 --- a/website/docs/observability/resource-view/storage-view/volume_attachement.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "VolumeAttachment" -sidebar_position: 33 ---- - -A [VolumeAttachment](https://kubernetes.io/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1/) captures the intent to attach or detach the specified volume to/from the specified node. - -![Insights](/img/resource-view/storage-volumeattachment.png) diff --git a/website/docs/observability/resource-view/workloads-view/_category_.json b/website/docs/observability/resource-view/workloads-view/_category_.json new file mode 100644 index 000000000..9e3a55f45 --- /dev/null +++ b/website/docs/observability/resource-view/workloads-view/_category_.json @@ -0,0 +1,3 @@ +{ + "collapsed": true +} diff --git a/website/docs/observability/resource-view/workloads-view/auth_authz_view.md b/website/docs/observability/resource-view/workloads-view/auth_authz_view.md new file mode 100644 index 000000000..29f6cb562 --- /dev/null +++ b/website/docs/observability/resource-view/workloads-view/auth_authz_view.md @@ -0,0 +1,43 @@ +--- +title: "Authentication and Authorization" +sidebar_position: 50 +--- + +Click on the **Authentication** tab to drill down to the ServiceAccounts section and you can view Kubernetes service account resources by namespace. + +:::info +Check out the [Security](../../../security/) module for additional examples. +::: +A [ServiceAccount](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) provides an identity for processes that run in a Pod. When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace. + +![Insights](/img/resource-view/auth-resources.jpg) + +To view additional details for a specific service account, drill down to the namespace and click on the service account you want to view to see additional information such as labels, annotations, events. Below is the detail view for the catalog service account. + +In EKS, you must be **authenticated** (logged in) before your request can be authorized (granted permission to access). Kubernetes expects attributes that are common to REST API requests. This means that EKS authorization works with [AWS Identity and Access Management](https://docs.aws.amazon.com/eks/latest/userguide/security-iam.html) for access control. + +In this lab, we'll view Kubernetes **Role Based Access Control (RBAC)** resources: Cluster Roles, Roles, ClusterRoleBindings and RoleBindings. RBAC is the process of providing restricted least privileged access to EKS clusters and its objects as per the IAM roles mapped to the EKS cluster users. Following diagram depicts how the access control flows when users or service accounts try to access the objects in EKS cluster through the Kubernetes client and API's. + +:::info +Check out the [Security](../../../security/) module for additional examples. +::: + +![Insights](/img/resource-view/autz-index.jpg) + +A **[Role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)** defines a set of permissions to be applied to a user. Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization. A Role always sets permissions within a particular namespace, when you create a Role, you have to specify the namespace it belongs in. + +Under **_Resource Type_** - **_Authorization_** section you can view **_ClusterRoles_** and **_Roles_** resources on your cluster listed by namespace. + +![Insights](/img/resource-view/autz-role.jpg) + +Click on the **_cluster-autoscaler-aws-cluster-autoscaler_** role to view more details for that **_role_**. The below screenshot shows the **_cluster-autoscaler-aws-cluster-autoscaler_** role created under namespace **_kube-system_** which has authorization to **_delete_**, **_get_**, and **_update_** on **_configmaps_** resources. + +![Insights](/img/resource-view/autz-role-detail.jpg) + +A **[ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole)** are a set of rules that are scoped to a cluster and not a namespace, which makes them different from a **_Role_**. **_ClusterRoles_** are additive, and you cannot set "deny" rules. You would generally use **_ClusterRoles_** to define cluster-wide permissions. + +A **[Role binding](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)** grants role permissions to a user or set of users. Rolebindings are assigned to a particular namespace during creation. The Rolebinding resource holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A **_RoleBinding_** grants permissions within a specific namespace like pods, replicasets, jobs, and deployments. Whereas a **_ClusterRoleBinding_** grants cluster scoped resources like nodes. + +A **[ClusterRoleBinding](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)** attach **_ClusterRoles_** to a set of users. They are scoped to a cluster, and are not bound to namespaces like **_Roles_** and **_RoleBindings_**. + +![Insights](/img/resource-view/authz-crolebinding.jpg) diff --git a/website/docs/observability/resource-view/workloads-view/cluster_view.md b/website/docs/observability/resource-view/workloads-view/cluster_view.md new file mode 100644 index 000000000..4abbda31c --- /dev/null +++ b/website/docs/observability/resource-view/workloads-view/cluster_view.md @@ -0,0 +1,19 @@ +--- +title: "Cluster" +sidebar_position: 10 +--- + +To view the Kubernetes cluster resources, click on the Resources tab. Drill down to the Cluster section and you can view several Kubernetes API resource types that are part of cluster. Cluster view details all the components of the cluster architecture like Nodes, Namespaces and API Services that run the workloads. + +Kubernetes runs your workload by placing containers into pods to run on [Nodes](https://kubernetes.io/docs/concepts/architecture/nodes/). A node may be a virtual or physical machine, depending on the cluster. The eks-workshop is running 3 nodes on which the workloads are deployed. Click on the Nodes drill down to list the nodes. + +![Insights](/img/resource-view/cluster-node.jpg) + +If you click on any of the node names, you will find the Info section that has a lot of details of the node - OS, container runtime, instance type, EC2 instance and [Managed node group](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) (that make it easy to provision compute capacity for the cluster). The next section, Capacity allocation shows usage and reservation of various resources on EC2 worker nodes connected to the cluster. + +![Insights](/img/resource-view/cluster-node-detail1.jpg) +The console also details all the pods provisioned on the node and any applicable [Taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/), labels, and annotations. + +[Namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces) are a mechanism to organize clusters which can be very helpful when different teams or projects share a Kubernetes cluster. In our sample application we have microservices - carts, checkout, catalog, assets which all share the same cluster using the namespace construct. + +![Insights](/img/resource-view/cluster-ns.jpg) diff --git a/website/docs/observability/resource-view/workloads-view/daemonset_view.md b/website/docs/observability/resource-view/workloads-view/daemonset_view.md deleted file mode 100644 index 07ee5bc32..000000000 --- a/website/docs/observability/resource-view/workloads-view/daemonset_view.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "DaemonSet" -sidebar_position: 55 ---- - -A [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) ensures that all (or some) Nodes run a copy of a pod. In the sample application we have DaemonSet running on each node as shown (below). - -![Insights](/img/resource-view/daemonset.jpg) - -Click on the daemonset kube-proxy and explore the configuration. You will see configurations under Info, pods running on each node, labels, and annotations. - -![Insights](/img/resource-view/daemonset-detail.jpg) diff --git a/website/docs/observability/resource-view/workloads-view/deployment_view.md b/website/docs/observability/resource-view/workloads-view/deployment_view.md deleted file mode 100644 index 737061715..000000000 --- a/website/docs/observability/resource-view/workloads-view/deployment_view.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "Deployments" -sidebar_position: 50 ---- - -A [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) is a Kubernetes object that provides declarative updates to pods and replicaSets. It tells Kubernetes how to create or modify instances of pods. Deployments help to scale the number of replica pods and enable rollout or rollback a deployment version in a controlled manner. In this example (below), you can see 2 deployments for namespace carts. - -![Insights](/img/resource-view/deploymentSet.jpg) - -Click on the deployment carts and explore the configuration. You will see deployment strategy under Info, pod details under Pods, labels and deployment revision. - -![Insights](/img/resource-view/deployment-detail.jpg) diff --git a/website/docs/observability/resource-view/workloads-view/extensions_view.md b/website/docs/observability/resource-view/workloads-view/extensions_view.md new file mode 100644 index 000000000..a3da8dc89 --- /dev/null +++ b/website/docs/observability/resource-view/workloads-view/extensions_view.md @@ -0,0 +1,27 @@ +--- +title: "CustomResourceDefinitions" +sidebar_position: 70 +--- + +[Extensions](https://kubernetes.io/docs/concepts/extend-kubernetes/) are software components that extend and deeply integrate with Kubernetes. In this lab exercise, we'll view common extension resource types including **_Custom Resource Definitions_**, **_Mutating Webhook Configurations_**, and **_Validating Webhook Configurations_** + +**[CustomResourceDefinitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions)** API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource. The name of a CRD object must be a valid **DNS subdomain name**. + +Under **_Resources_** - **_Extensions_** you can view a list of the **_Custom Resource Definitions_** on the cluster. + +**_Webhook_** configurations are executed during the process of intercepting authenticated API request to accept an object request or deny an object by _[Kubernetes Admission controllers](https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/)_. Kubernetes admission controllers sets a security baseline across namespace or cluster. The following diagram describes the different steps involved in the admission controller process. + +![Insights](/img/resource-view/ext-admincontroller.png) + +[Mutating admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) modify objects sent to the API server to enforce custom defaults. + +Under **_Resources_** - **_Extensions_** you can view a list of the **_Mutating Webhook Configurations_** on the cluster + +The below screenshot shows the details of the _aws-load-balancer-webhook_. You can see in this webhook configuration that `Match policy = Equivalent` which means +request will be sent to webhook by modifying the object as per the webhook version `Admission review version = v1beta1`. + +When the configuration `Match policy = Equivalent` then when a new request is processed but has a different webhook version then specified in the configuration, the request will not be sent to webhook. Notice the _Side Effects_ is set to `None` and the _Timeout Seconds_ is set to `10` meaning this webhook has no side effects and will be rejected after 10 seconds. + +![Insights](/img/resource-view/ext-mutatingwebhook-detail.jpg) + +**[Validating admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook)** validate requests to the API server. Their configuration includes settings to validate requests. Configurations of **_ValidatingAdmissionWebhooks_** are similar to **_MutatingAdmissionWebhook_**, however the final status of **_ValidatingAdmissionWebhooks_** request objects are stored in etcd. diff --git a/website/docs/observability/resource-view/workloads-view/index.md b/website/docs/observability/resource-view/workloads-view/index.md index 93908e6a7..8194615c7 100644 --- a/website/docs/observability/resource-view/workloads-view/index.md +++ b/website/docs/observability/resource-view/workloads-view/index.md @@ -1,6 +1,33 @@ --- -title: "Workloads" -sidebar_position: 50 +title: "Resources" +sidebar_position: 10 --- To view the Kubernetes resources, click on the Resources tab. Drill down to the Workload section and you can view several of the Kubernetes API resource types that are part of workloads. Workloads encompass the running containers in your cluster, and include Pods, ReplicaSets, Deployments, and DaemonSets. These are fundamental building blocks for running containers with a cluster. + +[Pods](https://kubernetes.io/docs/concepts/workloads/pods/) resource view displays all the pods which represent the smallest and simplest Kubernetes object. +By default, all Kubernetes API resource types are shown, but you can filter by namespace or search for specific values to find what you’re looking for quickly. Below you will see the pods filtered by the namespace=catalog + +![Insights](/img/resource-view/filter-pod.jpg) + +The resources view for all Kubernetes API resource types, offers two views - structured view and raw view. The structured view provides a visual representation of the resource to help access the data for the resource. Raw view shows the complete JSON output from the Kubernetes API, which is useful for understanding the configuration and state of resource types that do not have structured view support in the Amazon EKS console. + +![Insights](/img/resource-view/pod-detail-structured.jpg) + +A [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) is a Kubernetes object that ensures a stable set of replica pods are running at all times. As such, it is often used to guarantee the availability of a specified number of identical pods. In this example (below), you can see 2 replicasets for namespace orders. The replicaset for orders-d6b4566fc defines the configuration for desired and current number of pods. + +![Insights](/img/resource-view/replica-set.jpg) + +Click on the replicaset orders-d6b4566fc and explore the configuration. You will see configurations under Info, Pods, labels and details of max and desired replicas. + +A [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) is a Kubernetes object that provides declarative updates to pods and replicaSets. It tells Kubernetes how to create or modify instances of pods. Deployments help to scale the number of replica pods and enable rollout or rollback a deployment version in a controlled manner. In this example (below), you can see 2 deployments for namespace carts. + +![Insights](/img/resource-view/deploymentSet.jpg) + +Click on the deployment carts and explore the configuration. You will see deployment strategy under Info, pod details under Pods, labels and deployment revision. + +A [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) ensures that all (or some) Nodes run a copy of a pod. In the sample application we have DaemonSet running on each node as shown (below). + +![Insights](/img/resource-view/daemonset.jpg) + +Click on the daemonset kube-proxy and explore the configuration. You will see configurations under Info, pods running on each node, labels, and annotations. diff --git a/website/docs/observability/resource-view/workloads-view/pods_view.md b/website/docs/observability/resource-view/workloads-view/pods_view.md deleted file mode 100644 index a2b076e58..000000000 --- a/website/docs/observability/resource-view/workloads-view/pods_view.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "Pods" -sidebar_position: 30 ---- - -[Pods](https://kubernetes.io/docs/concepts/workloads/pods/) resource view displays all the pods which represent the smallest and simplest Kubernetes object. - -![Insights](/img/resource-view/view-pods.jpg) - -By default, all Kubernetes API resource types are shown, but you can filter by namespace or search for specific values to find what you’re looking for quickly. Below you will see the pods filtered by the namespace=catalog - -![Insights](/img/resource-view/filter-pod.jpg) - -The resources view for all Kubernetes API resource types, offers two views - structured view and raw view. The structured view provides a visual representation of the resource to help access the data for the resource. In this example (below), you can see a structured view for the catalog pod that breaks the pod information into Info, Containers, Labels and Annotations sections. It also details the associated replicaset, namespace and node. - -![Insights](/img/resource-view/pod-detail-structured.jpg) - -Raw view shows the complete JSON output from the Kubernetes API, which is useful for understanding the configuration and state of resource types that do not have structured view support in the Amazon EKS console. In the raw view example, we show the raw view for the catalog pod. - -![Insights](/img/resource-view/pod-detail-raw.jpg) diff --git a/website/docs/observability/resource-view/policy/index.md b/website/docs/observability/resource-view/workloads-view/policy_view.md similarity index 99% rename from website/docs/observability/resource-view/policy/index.md rename to website/docs/observability/resource-view/workloads-view/policy_view.md index 8169bddda..02980a655 100644 --- a/website/docs/observability/resource-view/policy/index.md +++ b/website/docs/observability/resource-view/workloads-view/policy_view.md @@ -1,6 +1,6 @@ --- title: "Policy" -sidebar_position: 120 +sidebar_position: 60 --- [Policies](https://kubernetes.io/docs/concepts/policy/) defines the cluster resource usages and restricts the deployment of _Kubernetes Objects_ to meet recommended best practices. Following are different types of policies that can be viewed at the cluster level in the **_Resource Types_** - **_Policy_** section diff --git a/website/docs/observability/resource-view/workloads-view/replicaset_view.md b/website/docs/observability/resource-view/workloads-view/replicaset_view.md deleted file mode 100644 index 394b7f193..000000000 --- a/website/docs/observability/resource-view/workloads-view/replicaset_view.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: "ReplicaSets" -sidebar_position: 40 ---- - -A [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) is a Kubernetes object that ensures a stable set of replica pods are running at all times. As such, it is often used to guarantee the availability of a specified number of identical pods. In this example (below), you can see 2 replicasets for namespace orders. The replicaset for orders-d6b4566fc defines the configuration for desired and current number of pods. - -![Insights](/img/resource-view/replica-set.jpg) - -Click on the replicaset orders-d6b4566fc and explore the configuration. You will see configurations under Info, Pods, labels and details of max and desired replicas. - -![Insights](/img/resource-view/rs-detail.jpg) diff --git a/website/docs/observability/resource-view/config-secret-view/configMap_view.md b/website/docs/observability/resource-view/workloads-view/secret_config_view.md similarity index 52% rename from website/docs/observability/resource-view/config-secret-view/configMap_view.md rename to website/docs/observability/resource-view/workloads-view/secret_config_view.md index 5bd703ea5..0efbf2b27 100644 --- a/website/docs/observability/resource-view/config-secret-view/configMap_view.md +++ b/website/docs/observability/resource-view/workloads-view/secret_config_view.md @@ -1,5 +1,5 @@ --- -title: "ConfigMaps" +title: "ConfigMaps and Secrets" sidebar_position: 30 --- @@ -11,4 +11,10 @@ Click on the ConfigMap drill down and you can see all the configs for the cluste If you click on the ConfigMap checkout you can see the properties associated with it, in this case, the key REDIS_URL with the value of the redis endpoint. As you can see, the value is not encrypted and ConfigMaps should not be used to store any confidential key-value pairs. -![Insights](/img/resource-view/config-configmap-1.jpg) +[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) is a Kubernetes resource object for storing sensitive pieces of data such as username, passwords, tokens, and other credentials. Secrets are helpful to organize and distribute sensitive information across the pods in a cluster. Secrets can be used in a variety of ways, such as being mounted as data volumes or exposed as environment variables to be used by a container in a Pod. + +Click on the Secrets drill down and you can see all the secrets for the cluster. + +![Insights](/img/resource-view/config-secrets.jpg) + +If you click on the Secrets checkout-config you can see the secrets associated with it. In this case, notice the encoded token. You should see the decoded value as well with the decode toggle button. diff --git a/website/docs/observability/resource-view/service-networking-view/service_view.md b/website/docs/observability/resource-view/workloads-view/service_view.md similarity index 58% rename from website/docs/observability/resource-view/service-networking-view/service_view.md rename to website/docs/observability/resource-view/workloads-view/service_view.md index f005d701a..4ad886395 100644 --- a/website/docs/observability/resource-view/service-networking-view/service_view.md +++ b/website/docs/observability/resource-view/workloads-view/service_view.md @@ -1,24 +1,17 @@ --- title: "Services and Endpoints" -sidebar_position: 30 +sidebar_position: 20 --- +To view the Kubernetes service and networking resources, click on the Resources tab. Drill down to the Service and Networking section and you can view several the Kubernetes API resource types that are part of service and networking. This lab exercise details ways to expose an application running on a set of Pods as Service, Endpoints and Ingresses. + [Service](https://kubernetes.io/docs/concepts/services-networking/service/) resource view displays all the services that expose applications running on set of pods in a cluster. ![Insights](/img/resource-view/service-view.jpg) If you select the service cart the view displayed will have details about the service in Info section including selector(The set of pods targeted by a service is usually determined by a selector), the protocol and port it is running on and any labels and annotations. - -![Insights](/img/resource-view/service-detail.jpg) - Pods expose themselves through endpoints to a service. An endpoint is an resource that gets an IP address and port of pods assigned dynamically to it. An endpoint is reference by a Kubernetes service. ![Insights](/img/resource-view/service-endpoint.png) -For this sample application, click on Endpoints and it will list all the endpoints for your cluster. - -![Insights](/img/resource-view/service-endpoint.jpg) - -Click on the catalog endpoint and when you explore the details you can see the IP address and port associated with the endpoint along with Info, Labels and Annotations sections. - -![Insights](/img/resource-view/service-endpoint-detail.jpg) +For this sample application, click on Endpoints and explore the details of the IP address and port associated with the endpoint along with Info, Labels and Annotations sections. diff --git a/website/docs/observability/resource-view/workloads-view/storage_view.md b/website/docs/observability/resource-view/workloads-view/storage_view.md new file mode 100644 index 000000000..c113ccf61 --- /dev/null +++ b/website/docs/observability/resource-view/workloads-view/storage_view.md @@ -0,0 +1,26 @@ +--- +title: "Storage" +sidebar_position: 40 +--- + +To view the Kubernetes storage resources, click on the Resources tab. Drill down to the Storage section and you can view several the Kubernetes API resource types related to storage that are part of cluster including: + +- Persistent Volume Claims +- Persistent Volumes +- Storage Classes +- Volume Attachments +- CSI Drivers +- CSI Nodes + +The [Storage](../../../fundamentals/storage/) workshop module goes into more details on how to configure and use storage for stateful workloads. + +[PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) (PVC) is a request for storage by a user. This resource is similar to Pods. Pods consume node resources and PVCs consume Persistent Volume (PV) resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany. See [AccessModes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) for more information) + +[PersistentVolume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) A PersistentVolume (PV) is a configured unit of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/). It's a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that EBS, EFS or other third party PV providers. + +[StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes/) provides a way for administrators to describe the "classes" of storage that are available to a cluster. Different classes might map to quality-of-service levels, or to backup policies, or to arbitrary policies determined by cluster administrators. + +[VolumeAttachment](https://kubernetes.io/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1/) captures the intent to attach or detach the specified volume to/from the specified node. + +[Container Storage Interface (CSI)](https://kubernetes.io/docs/concepts/storage/volumes/#csi) defines a standard interface for Kubernetes to expose arbitrary storage systems to container workloads. +Container Storage Interface (CSI) node plugins are needed to perform various privileged operations like scanning of disk devices and mounting of file systems. These operations differ for each host operating system. For Linux worker nodes, containerized CSI node plugins are typically deployed as privileged containers. For Windows worker nodes, privileged operations for containerized CSI node plugins is supported using [csi-proxy](https://github.com/kubernetes-csi/csi-proxy), a community-managed, stand-alone binary that needs to be pre-installed on each Windows node. diff --git a/website/static/img/resource-view/eks-overview.jpg b/website/static/img/resource-view/eks-overview.jpg index 319767e7d..8e3581d5a 100644 Binary files a/website/static/img/resource-view/eks-overview.jpg and b/website/static/img/resource-view/eks-overview.jpg differ diff --git a/website/static/img/resource-view/eks-overview.png b/website/static/img/resource-view/eks-overview.png deleted file mode 100644 index 6efcb322a..000000000 Binary files a/website/static/img/resource-view/eks-overview.png and /dev/null differ diff --git a/website/static/img/resource-view/find-add-ons.jpg b/website/static/img/resource-view/find-add-ons.jpg new file mode 100644 index 000000000..95c179c31 Binary files /dev/null and b/website/static/img/resource-view/find-add-ons.jpg differ diff --git a/website/static/img/resource-view/observability-view.jpg b/website/static/img/resource-view/observability-view.jpg new file mode 100644 index 000000000..2752bd542 Binary files /dev/null and b/website/static/img/resource-view/observability-view.jpg differ diff --git a/website/static/img/resource-view/pod-detail-structured.jpg b/website/static/img/resource-view/pod-detail-structured.jpg index 3e7ba4fe9..1b2c3ed6e 100644 Binary files a/website/static/img/resource-view/pod-detail-structured.jpg and b/website/static/img/resource-view/pod-detail-structured.jpg differ diff --git a/website/static/img/resource-view/select-add-ons.jpg b/website/static/img/resource-view/select-add-ons.jpg new file mode 100644 index 000000000..bf00911f2 Binary files /dev/null and b/website/static/img/resource-view/select-add-ons.jpg differ