This is actually pretty well described in the docs.
Before you create worker nodes, you must create an IAM role with the
following IAM policies:
Also you need to make sure that this role could be assumed by EKS.
Is it possible to declare "a complete production level EKS with other aws services" using terraform?
Yes, and that is what many larger organizations do. I have implemented Kubernetes with other AWS resources this way for larger companies e.g. a bank, using Terraform.
I want to learn aws by experimenting. But I cannot afford spending that much ...
But from what I've understood Fargate is more suitable for container that have a limited lifetime?
That's not strictly correct, Fargate capabilities include tasks which are suitable for short-term limited lifetime tasks as well as services which are designed to run all the time.
For sure, Fargate is more expensive as compared to EC2 - but you don't need to ...
Fargate is absolutely suitable for web apps. We have many customers that use it that way (and many others that use it in a more "batchy" way). Fargate is a managed compute engine and AWS takes a more responsibilities in terms of scaling, patching, security, and so forth so comparing raw Fargate costs to raw EC2 costs isn't how I would compare them. ...
You should look into affinity and anti-affinity as that allows you to control what pods go on which node. You can have it so that with anti-affinity there is only 1 pod of each deployment on a node. This is a bit overkill and wouldn't work for you exactly though IIRC you can have multiple pods on a node just with a limit.
Yes It does more than just creating a service account. It does three things:
It Creates an IAM role.
It attaches the desired iam-policy (--attach-policy-arn
<POLICY_ARN>) to the created IAM role.
It creates a new kubernetes service account annotated with the arn of the created IAM role.
Now It's easy to declare the above steps using kubernetes and ...
You can't configure your Ingress to serve static data (from your host files for example) alone because the Ingress resource is just a way to configure a way of understanding for Kubernetes on how to access a specific internal resource from outside the cluster.
An API object that manages external access to the services in a cluster, typically HTTP.
This is more of an opinion based question but let me try to answer it.
installing Prometheus itself in the very same k8s cluster (as another running set of pods) is a normal thing.Am I right or just got a wrong idea from my research?
Considering good practices, shouldn't the monitoring tool be outside of the system that you actually intend to monitor?
Nope, Fargate can be used for long running containerized workloads. Web apps, proxies, or any other containers. Maybe you are thinking of Fargate Spot? Fargate Spot is definitely not suitable for long running containers, and should only be used for running workloads that can be safely interrupted or stopped unexpectedly. This is because AWS is able to retake ...
For Amazon EKS, the control plane is running in a separate VPC that is managed by Amazon. You only need to care about the VPC for the worker nodes.
Amazon EKS control plane – Deployed and managed by Amazon EKS in an Amazon EKS managed VPC. When you create the cluster, Amazon EKS creates and manages network interfaces in your account that have Amazon EKS in ...
Take a look at the Descheduler. This project runs as a Kubernetes Job that aims at killing pods when it thinks the cluster is unbalanced.
The LowNodeUtilization strategy seems to fit your case:
This strategy finds nodes that are under utilized and evicts pods, if
possible, from other nodes in the hope that recreation of evicted pods
will be scheduled on ...
From the same page:
The steps to integrate ALB and NLB with API Gateway are identical.
Which is followed by a sentence with a link to a documentation for an ALB ingress, including prerequisites for VPC subnets and EKS resources.
Yes, you have to create one unless you'd want to configure ALB manually instead of using Ingress manifests inside k8s.
In terms of general positioning this may be a good starting point.
Given in the title you mention "hybrid" deployments you may be interested in investigating and investigating ECS Anywhere and EKS Anywhere. They are both coming in 2021.
I am not sure it will be helped. I have similar design in my office.
I have some Kubernetes Cluster. all node and master running on local ip from a PVC. And my rds too, only have local ip run on same PVC. Kubernetes Cluster already connect to RDS using local ip.
Then, I build VPN server on bastion server. Have local ip and public ip, run on same PVC with RDS ...
The only way to manage IAM users - using appropriate account with IAM Administrator privileges.
See AWS Identity and Access Management
If you lost your root account, you may contact an AWS support, see Recover Your AWS Account Password