Quote
Hi @all, I back after previous week spend for couple stuff of myself, recover and love π. How is your holiday?, itβs starting right, I hope you have good time with family and enjoy your holiday. Today, I think that one is the last article about technologies before new year, cuz I want to spend next week for recap session, so enjoy the topics today. In today session, we will learn how can you work with EKS and implement for your cluster once monitoring stack. Letβs digest
How can we work with EKS
Question
When you kick off new EKS, I believe you can messup a bit with how we can setup the authentication to help
kubectl
oraws
can retrieve the information inside Kubernetes Cluster viaKubernetes API
. This one is really interesting question
I need spend a couple of hours to see how this work, because I need to access to cluster to see what happen inside EKS Milvus Cluster, you can explore more information at First EKS Cluster with Milvus DB.
Methodology to authenticate
When I first time to use EKS
, Itβs totally different than AKS. And I reach to how to configuration the permission to help this blocker resolved, through
- AWS Docs - Grant IAM users and roles access to Kubernetes APIs
- AWS Docs - Associate access policies with access entries
- AWS Docs - Actions, resources, and condition keys for Amazon Elastic Kubernetes Service
There is many ways to authenticate, and you can catch up that really exist in two types
- An AWS Identity and Access Management (IAM)Β principalΒ (role or user)Β β This type requires authentication to IAM. Users can sign in to AWS as anΒ IAMΒ user or with aΒ federated identityΒ by using credentials provided through an identity source.
- A user in your own OpenID Connect (OIDC) providerΒ β This type requires authentication to yourΒ OIDCΒ provider. For more information about setting up your own OIDC provider with your Amazon EKS cluster, seeΒ Grant users access to Kubernetes with an external OIDC provider.
Note
Following my situation, I prefer to use AWS IAM because itβs kinda easily to configuration because Iβam using IAM Identity Center that way can really help grant access for role assume for my shell to using
kubeconfig
viakubectl
To enable this feature, you can follow in couple of steps in next part
Cluster Authenticated Mode and IAM Identities
If you choose follow to use IAM principal (role and user) to access Kubernetes
, you need to follow methods to allow your IAM principal to access Kubernetes
object in your cluster, including
- Creating access entries
- Adding entries to theΒ
aws-auth
ΒConfigMap
In term of mine, I am using access entries to access to Kubernetes
but itβs kinda require you choose once of two option depend on your cluster version and platform version. Explore more at Associate IAM Identities with Kubernetes Permissions. If you wanna easily, you should use access entries
than aws-auth
To set access entries
available, you have couple stuff do with Cluster Authentication Mode because you need to set your cluster determine to permit your IAM principals be able to access Kubernetes
object. There are three mode you can set for your Cluster, including
- TheΒ
aws-auth
ΒConfigMap
Β inside the cluster (Original) - Both theΒ
ConfigMap
Β and access entries - Access entries only
In my perspective, you can choose to use both because I donβt wanna corrupt anything because you know that tuff if you want intercept any problem from your Cluster to AWS Service integrated like MilvusDB, so for ensure, I enable both, and when you apply it you can see the authentication mode of cluster like
Awesome, now you can turn back and add the entry depend on your definition. If you want explore more way to configuration EKS cluster authentication mode, donβt forget to double-check blog A deep dive into simplified Amazon EKS access management controls
Configure IAM Access Entry
Info
As you know about I use IAM Identity Center to configure authentication and authorization for user and group to access AWS Resources. With IAM Access Entry for EKS, Itβs not exception, I need to add the policies to grant account can describe EKS Cluster configuration for retrieving
kubeconfig
to current shell
First of all, back to terraform
configuration to configure add-on policies, you can consider to provide policy AmazonEKSWorkerNodePolicy
because you need permission eks:DescribeCluster
to get kubeconfig
and this policy actual contains it, so hit to terraform
and do it for yourself. Explore at Reuse with your AWS SSO module
Now apply terraform
and you can describe your EKS Cluster with AWS Portal, It gains you permission to retrieve kubeconfig
through command
You just need to setup it for Developer because if you have administrator to access AWS, you may need have permission to view and configuration tons of things with EKS. BTW, you need to request DevOps or AWS Admin to create access entries for your DeveloperServiceAccess
role. You can follow step at AWS Docs - Create access entries
I prefer the way to create this entries through AWS Portal, kinda convenient and after you complete, who have DeveloperServiceAccess
can able to use this access Kubernetes object. BTW you need consider what policy provide for this role inside Kubernetes cluster, you can double-check at AWS Docs - Review access policy permissions
Note
In my situation, I like give permission
AmazonEKSClusterAdminPolicy
for who is Administrator of EKS Cluster andAmazonEKSViewPolicy
for who is developer of EKS Cluster
Now you can try to export profile with AWS SSO, and see what happen with your developer permission
And Itβs work recently, you can retrieve pods
, logs
inside your target EKS Cluster. If you want to retrieve the metrics
through metrics.k8s.io
, you need to grant permission from AmazonEKSViewPolicy
to AmazonEKSAdminViewPolicy
(Note: Secret be able to view with this permission)
Success
Now you can access and practice with EKS Cluster from both AWS Portal and your local machine with
kubectl
EKS Cluster Monitoring and Observability
Quote
As you can see, when you access Kubernetes, you can use
kubectl
to view bothmetrics
andlogs
but you know but in term of developer, that kinda tuff when they first face up withkubectl
andkubernetes
so read all of these output inside the shell can be tough. But, AWS always offer another way to monitor and observer the EKS Cluster through CloudWatch or Grafana/Prometheus, Itβs up to you to choose one of these to operating for your cluster
For me, CloudWatch is such a good thing, so we can try follow that implementation leverage that one to create fully stack to directly monitor your EKS Cluster, letβs check it out
Intercept metrics and logs with Cloudwatch Agents
First of all, I need to figure how we can do, so reach to couple blog and documentation of AWS to explore more information, such as
- AWS Docs - Monitor your cluster performance and view logs
- AWS Docs - Setting up Container Insights on Amazon EKS and Kubernetes
- AWS Docs - Quick Start setup for Container Insights on Amazon EKS and Kubernetes
- AWS Docs - Setting up the CloudWatch agent to collect cluster metrics
- AWS Docs - Send logs to CloudWatch Logs
- AWS Docs - Set up Fluent Bit as a DaemonSet to send logs to CloudWatch Logs
- Medium - Streamlining Logging and Monitoring in Amazon EKS with Fluentd and CloudWatch Agent
- AWS Blogs - Fluent Bit Integration in CloudWatch Container Insights for EKS
- GitHub - amazon-cloudwatch-container-insights - CloudWatch Agent Dockerfile and K8s YAML templates for CloudWatch Container Insights.
After spend a bit time to read and view couple results from implementation, so I decide to install stack to monitor cluster, including
- CloudWatch Agent - Scrape metrics
- Fluentbit - Scrape logs
To easier in implementation, so I try retrieve a fully manifest combine both CloudWatch Agent and Fluentbit, you can double check before install inside your cluster. Explore it at cwagent-fluent-bit-quickstart-enhanced.yaml
Warning
You need to modify two parameter inside the manifest, including
- CWAgent
{{cluster_name}}
by your cluster name (e.g: milvus-cluster){{region_name}}
by your region deployed EKS (e.g: ap-southeast-1)
- Fluentbit: Explore at Setting up Fluent Bit
cluster.name: {{cluster_name}}
by your cluster name (e.g: milvus-cluster)logs.region: {{region_name}}
by your region deployed EKS (e.g: ap-southeast-1)http.server: {{http_server_toggle}}
(e.g: βOffβ)http.port: {{http_server_port}}
(e.g: β2020β)read.head: {{read_from_head}}
(e.g: βOffβ)read.tail: {{read_from_tail}}
(e.g: βOnβ)
Now you can apply manifest and see the result expose from your EKS Cluster, but remember login into Administrator role to have permission write into cluster
Warning
Take a guess, Itβs totally failure because we forgot setup the legit important to gain permission EKS Cluster have put logs and metrics to
CloudWatch
. Back to this configuration at AWS Docs - Verifying prerequisites for Container Insights in CloudWatch
As you can see, we need provide more permission into role attached with EKS Cluster to help send logs and metrics to cloudwatch through that one, CloudWatchAgentServerPolicy need to be configured
After you make sure anything work with your node group, you can apply manifest again and see the result.
Success
Boom, successfully you totally view both metrics and logs inside your CloudWatch
Couple of results when deployed successful
Workload of EKS Monitoring
With metrics, CWAgent
will send that into CloudWatch
in metrics ContainerInsights
With logs, Fluentbit
will send that into CloudWatch
as log groups in context
- /aws/containerinsights/Cluster_Name/application
- /aws/containerinsights/Cluster_Name/host
- /aws/containerinsights/Cluster_Name/dataplane
- /aws/containerinsights/Cluster_Name/performance
Success
Now you can take a look and debug directly your cluster through CloudWatch Portal, truly convenient btw consider your cost paid for that. If you think that really work, go for it that really cool stuff you can make bit for your EKS Cluster
Conclusion
Success
Well, this is all for this weekend, really cool stuff and I learn a lots when setup the permission and monitoring stack for EKS, maybe this article is last article that write about AWS Cloud and Service, cuz I will move on on the next stage of my career and see what the different zone I can inspect, learn and enjoy a lots, upset to say that but donβt worry if anything new about AWS, I will turn back soon. BTW, letβs see what next articles on new year bring up the different stuff in my site. Again, that really memorable with Cloud Services and I will remember a lot, now letβs celebrate for the last one π»
Quote
Hope you find well information and learn a lots of techniques through this blog. This one can be last Cloud Services article, last technology articles for this year cuz I will spend next week for my 2024 recap session. I hope yβall have happiness holiday with family and friend, take a rest, recover and turn back with positive energy. So one again, thank for standing with me during this year, this is very meaningful with my growth, therefore stay safe, learn new thing and see yeah on next year at the first weekend session. Happy holiday, merry christmas and happy new year 2025. Bye Bye π