Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/chukwuemekaaham/argocd_eks_reskill
AWS EKS reskill
https://github.com/chukwuemekaaham/argocd_eks_reskill
add-ons alb argocd aws aws-load-balancer-controller cicd eks eksctl grafana-dashboard helm ingress irsa k8s kubectl kustomize nlb prometheus terraform
Last synced: 3 days ago
JSON representation
AWS EKS reskill
- Host: GitHub
- URL: https://github.com/chukwuemekaaham/argocd_eks_reskill
- Owner: ChukwuemekaAham
- Created: 2024-07-09T06:05:30.000Z (6 months ago)
- Default Branch: main
- Last Pushed: 2024-07-09T16:24:15.000Z (6 months ago)
- Last Synced: 2024-12-19T02:10:57.108Z (3 days ago)
- Topics: add-ons, alb, argocd, aws, aws-load-balancer-controller, cicd, eks, eksctl, grafana-dashboard, helm, ingress, irsa, k8s, kubectl, kustomize, nlb, prometheus, terraform
- Language: HCL
- Homepage:
- Size: 9.03 MB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Sample application
The sample application models a simple web store application, where customers can browse a catalog, add items to their cart and complete an order through the checkout process.
The application has several components and dependencies:
## Component description
UI - Provides the front end user interface and aggregates API calls to the various other services.
Catalog - API for product listings and details
Cart - API for customer shopping carts
Checkout - API to orchestrate the checkout process
Orders - API to receive and process customer orders
Static assets - Serves static assets like images related to the product catalog
ComponentDescriptionUIProvides the front end user interface and aggregates API calls to the various other services.CatalogAPI for product listings and detailsCartAPI for customer shopping cartsCheckoutAPI to orchestrate the checkout processOrdersAPI to receive and process customer ordersStatic assetsServes static assets like images related to the product catalog
Initially we'll deploy the application in a manner that is self-contained in the Amazon EKS cluster, without using any AWS services like load balancers or a managed database.
Over the course of the labs we'll leverage different features of EKS to take advantage of broader AWS services and features for our retail store.
You can find the full source code for the sample application on .
# Setting Up EKS Cluster
see ~/setup folder
```bash
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-192-168-32-131.us-east-2.compute.internal Ready 9h v1.23.17-eks-ae9a62a
ip-192-168-79-172.us-east-2.compute.internal Ready 9h v1.23.17-eks-ae9a62a
ip-192-168-8-139.us-east-2.compute.internal Ready 9h v1.23.17-eks-ae9a62a
```
# Packaging the components
Before a workload can be deployed to a Kubernetes distribution like EKS it first must be packaged as a container image and published to a container registry. Basic container topics like this are not covered as part of this workshop, and the sample application has container images already available in Amazon Elastic Container Registry for the labs we'll complete today.
The table below provides links to the ECR Public repository for each component, as well as the Dockerfile that was used to build each component.
ComponentECR Public repositoryDockerfileUIRepositoryDockerfileCatalogRepositoryDockerfileShopping cartRepositoryDockerfileCheckoutRepositoryDockerfileOrdersRepositoryDockerfileAssetsRepositoryDockerfile
# Microservices on Kubernetes
Let's explore some of the Kubernetes building blocks by looking at the catalog component:
Let's explore some of the Kubernetes building blocks by looking at the catalog component:
Catalog microservice in Kubernetes
There are a number of things to consider in this diagram:
- The application that provides the catalog API runs as a Pod, which is the smallest deployable unit in Kubernetes. Application Pods will run the container images we outlined in the previous section.
- The Pods that run for the catalog component are created by a Deployment which may manage one or more "replicas" of the catalog Pod, allowing it to scale horizontally.
- A Service is an abstract way to expose an application running as a set of Pods, and this allows our catalog API to be called by other components inside the Kubernetes cluster. Each Service is given its own DNS entry.
- MySQL database that runs inside our Kubernetes cluster as a StatefulSet, which is designed to manage stateful workloads.
- All of these Kubernetes constructs are grouped in their own dedicated catalog Namespace. Each of the application components has its own Namespace.
Each of the components in the microservices architecture is conceptually similar to the catalog, using Deployments to manage application workload Pods and Services to route traffic to those Pods. If we expand out our view of the architecture we can consider how traffic is routed throughout the broader system:
The ui component receives HTTP requests from, for example, a users browser. It then makes HTTP requests to other API components in the architecture to fulfill that request and returns a response to the user. Each of the downstream components may have their own data stores or other infrastructure. The Namespaces are a logical grouping of the resources for each microservice and also act as a soft isolation boundary, which can be used to effectively implement controls using Kubernetes RBAC and Network Policies.
# Deploying our component
The sample application is composed of a set of Kubernetes manifests organized in a way that can be easily applied with Kustomize. Kustomize is an open-source tool also provided as a native feature of the kubectl CLI. This workshop uses Kustomize to apply changes to Kubernetes manifests, making it easier to understand changes to manifest files without needing to manually edit YAML. Kustomize was used to incrementally apply overlays and patches.
**lets inspect the current Namespaces in our EKS cluster:**
```bash
$ kubectl apply -k ./base-application
$ kubectl get namespaces
NAME STATUS AGE
argocd Active 7h38m
assets Active 64m
carts Active 64m
catalog Active 64m
checkout Active 64m
default Active 9h
kube-node-lease Active 9h
kube-public Active 9h
kube-system Active 9h
orders Active 64m
other Active 64m
rabbitmq Active 64m
ui Active 64m
$ kubectl get deployment -l app.kubernetes.io/created-by=eks-workshop -A
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
assets assets 1/1 1 1 65m
carts carts 1/1 1 1 65m
carts carts-dynamodb 1/1 1 1 65m
catalog catalog 1/1 1 1 64m
checkout checkout 1/1 1 1 64m
checkout checkout-redis 1/1 1 1 64m
orders orders 1/1 1 1 64m
orders orders-mysql 1/1 1 1 64m
ui ui 3/3 3 3 65m
```
# Helm
Although we primarily interact with kustomize, there will be situations where Helm will be used to install certain packages in the EKS cluster.
Helm is a package manager for Kubernetes that helps you define, install, and upgrade Kubernetes applications. It uses a packaging format called charts, which contain all the necessary Kubernetes resource definitions to run an application. Helm simplifies the deployment and management of applications on Kubernetes clusters.
## Helm CLI
The helm CLI tool is typically used in conjunction with a Kubernetes cluster to manage the deployment and lifecycle of applications. It provides a consistent and repeatable way to package, install, and manage applications on Kubernetes, making it easier to automate and sta
`$ helm version`
## Helm repositories
A Helm repository is a centralized location where Helm charts are stored and managed, and allow users to easily discover, share, and install charts. They facilitate easy access to a wide range of pre-packaged applications and services for deployment on Kubernetes clusters.
The Bitnami Helm repository is a collection of Helm charts for deploying popular applications and tools on Kubernetes. Let's add the bitnami repository to our Helm CLI:
```bash
$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm repo update
Now we can search the repository for charts, for example the postgresql
$ helm search repo postgresql
NAME CHART VERSION APP VERSION DESCRIPTION
bitnami/postgresql X.X.X X.X.X PostgreSQL (Postgres) is an open source object-...
[...]
```
## nstalling a Helm chart
Let's install an NGINX server in our EKS cluster using the Helm chart we found above. When you install a chart using the Helm package manager, it creates a new release for that chart. Each release is tracked by Helm and can be upgraded, rolled back, or uninstalled independently from other releases.
```bash
$ echo $NGINX_CHART_VERSION
$ helm install nginx bitnami/nginx \
--version $NGINX_CHART_VERSION \
--namespace nginx --create-namespace --wait
```
We can break this command down as follows:
- Use the install sub-command to instruct Helm to install a chart
Name the release nginx
- Use the chart bitnami/nginx with the version $NGINX_CHART_VERSION
Install the chart in the nginx namespace and create that namespace first
- Wait for pods in the release to get to a ready state
- Once the chart has installed we can list the releases in our EKS cluster:
```bash
$ helm list -A
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
nginx nginx 1 2024-06-11 03:58:39.862100855 +0000 UTC deployed nginx-X.X.X X.X.X
We can also see NGINX running in the namespace we specified:
$ kubectl get pod -n nginx
NAME READY STATUS RESTARTS AGE
nginx-55fbd7f494-zplwx 1/1 Running 0 119s
```
## Configuring chart options
In the example above we installed the NGINX chart in its default configuration. Sometimes you'll need to provide configuration values to charts during installation to modify the way the component behaves.
There are two common ways to provide values to charts during installation:
Create YAML files and pass them to Helm using the -f or --values flag
Pass values using the --set flag followed by key=value pairs
Let's combine these methods to update our NGINX release. We'll use this values.yaml file:
./introduction/helm/values.yaml
podLabels:
team: team1
costCenter: org1
resources:
requests:
cpu: 250m
memory: 256Mi
This adds several custom Kubernetes labels to the NGINX pods, as well as setting some resource requests.
We'll also add additional replicas using the --set flag:
```bash
$ helm upgrade --install nginx bitnami/nginx \
--version $NGINX_CHART_VERSION \
--namespace nginx --create-namespace --wait \
--set replicaCount=3 \
--values ./introduction/helm/values.yaml
# List the releases:
$
helm list -A
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
nginx nginx 2 2024-06-11 04:13:53.862100855 +0000 UTC deployed nginx-X.X.X X.X.X
# You'll notice that the revision column has updated to 2 as Helm has applied our updated configuration as a distinct revision. This would allow us to rollback to our previous configuration if necessary.
# You can view the revision history of a given release like this:
$ helm history nginx -n nginx
REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
1 Tue Jun 11 03:58:39 2024 superseded nginx-X.X.X X.X.X Install complete
2 Tue Jun 11 04:13:53 2024 deployed nginx-X.X.X X.X.X Upgrade complete
# To check that our changes have taken effect list the pods in the nginx namespace:
$ kubectl get pods -n nginx
NAME READY STATUS RESTARTS AGE
nginx-55fbd7f494-4hz9b 1/1 Running 0 30s
nginx-55fbd7f494-gkr2j 1/1 Running 0 30s
nginx-55fbd7f494-zplwx 1/1 Running 0 5m
# You can see we now have 3 replicas of the NGINX pod running.
# Removing releases
# We can similarly uninstall a release using the CLI:
$ helm uninstall nginx --namespace nginx --wait
# This will delete all the resources created by the chart for that release from our EKS cluster.