1일차 : 팀 구성 및 프로젝트 구상
2일차 : kops 구축
3일차 : Autoscaling 설정
3일차 issue
CA(Cluster Autoscaling) apply 시 파드 CrashLoopBackOff
State: Waiting
Reason: RunContainerError
Last State: Terminated
Reason: StartError
Message: failed to create containerd task: failed to create shim task: OCI runtime create failed:
runc create failed: unable to start container process: error during container init:
error mounting "/etc/ssl/certs/ca-bundle.crt" to rootfs at "/etc/ssl/certs/ca-certificates.crt":
mount /etc/ssl/certs/ca-bundle.crt:/etc/ssl/certs/ca-certificates.crt (via /proc/self/fd/6),
flags: 0x5001: not a directory: unknown
Exit Code: 128
Started: Thu, 01 Jan 1970 09:00:00 +0900
Finished: Wed, 02 Oct 2024 20:11:21 +0900
Ready: FalseSSL 인증서 파일 마운트 실패
Ubuntu 시스템에서는 일반적으로 CA 인증서 번들 파일이 ca-certificates.crt라는 이름으로 존재하는데
volumes의 hostPath에서 주로 RedHat 계열 시스템에서 사용되는 이름인 /etc/ssl/certs/ca-bundle.crt로 마운트 하려고 하기 때문
[root@ip-172-31-46-129: ~]$ ls -l /etc/ssl/certs/ca-bundle.crt
ls: cannot access '/etc/ssl/certs/ca-bundle.crt': No such file or directory
path를 변경하여 해결
E1002 11:26:23.155284 1 aws_manager.go:125] Failed to regenerate ASG cache: MissingRegion: could not find region configuration
F1002 11:26:23.155303 1 aws_cloud_provider.go:419] Failed to create AWS Manager: MissingRegion: could not find region configurationCA yaml 설정파일에서 Region이 명시되지 않았기 때문에 발생
region을 추가했음에도 오류
--region 플래그는 CA 최신 버전에서 지원하지 않기 때문
--region 플래그 대신 환경 변수로 AWS 리전 설정
수정했음에도 CrashLoopBackOff
E1002 11:51:14.900517 1 aws_manager.go:125] Failed to regenerate ASG cache: NoCredentialProviders: no valid providers in chain. Deprecated.
For verbose messaging see aws.Config.CredentialsChainVerboseErrors
F1002 11:51:14.900553 1 aws_cloud_provider.go:419] Failed to create AWS Manager: NoCredentialProviders: no valid providers in chain. Deprecated.
For verbose messaging see aws.Config.CredentialsChainVerboseErrorscluster-autoscaler가 AWS API에 액세스할 수 없어서 발생하는 문제
EC2 인스턴스의 IAM 권한 확인 : O
노드 그룹의 IAM 역할에 Autoscaling 권한 여부 : O
- autoscaling:DescribeAutoScalingGroups
- autoscaling:DescribeAutoScalingInstances
- autoscaling:DescribeLaunchConfigurations
- autoscaling:DescribeTags
- autoscaling:SetDesiredCapacity
- autoscaling:TerminateInstanceInAutoScalingGroup
- ec2:DescribeLaunchTemplateVersionsAutoScaling 그룹에 태그 추가 여부 : O
- Key: k8s.io/cluster-autoscaler/<your-cluster-name>
- Value: owned
- Key: k8s.io/cluster-autoscaler/enabled
- Value: true적절한 역할과 태그가 주어졌지만 여전히 CrashLoopBack 발생,
kops로 k8s를 설치한 경우, 워커 노드에 IAM 권한을 직접 추가해주는 것과 더불어 CA 파드가 AWS API에 액세스할 수 있는 방식으로 IAM 역할을 설정해야 한다고 함
EKS와 다르게 kops는 자동으로 IRSA(EKS에서 자주 사용하는 방식)를 지원하지 않기 때문에 수동으로 명시적으로 추가 설정 필요
CA설정 yaml 파일에 annotation 추가
template:
metadata:
annotations:
iam.amazonaws.com/role: arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME
labels:
app: cluster-autoscaler하지만 여전히 CrashLoopBack 오류 발생
-----해결중-----
해결 예정 내용
EKS에서는 IAM 역할을 파드와 직접 연결하는 IRSA(IAM Roles for Service Accounts) 방식이 지원, 이를 통해 AWS 리소스에 접근할 때 자동으로 권한이 부여되며, AWS CLI 설정이 없어도 IAM 역할을 통해 자동으로 인증이 이루어짐
하지만 kops에서는 AWS CLI가 제대로 설정되어 있지 않으면 AWS API에 대한 인증이 제대로 이루어지지 않을 수 있음
이로 인해 Cluster Autoscaler(CA)가 AWS 리소스에 접근할 수 없게 되며, 이로 인해 NoCredentialProviders 오류가 발생할 수 있음
즉, CA 설정 YAML 파일에서 arn을 설정해주더라도, AWS CLI나 인증 설정이 올바르게 구성되지 않으면 AWS API에 접근할 수 없기 때문에 CA가 제대로 작동하지 않게 됨
aws sts get-caller-identity 명령어를 통해 현재 AWS CLI가 제대로 설정되었는지 확인
ca yaml에서 nodeSelector로 워커 노드에 배치되어있는지 tolerations로 마스터 노드에 배치되어있는지 확인
EKS
IRSA(IAM Roles for Service Accounts) 기능을 사용하여, Kubernetes 서비스 계정에 IAM 역할을 매핑하면 해당 서비스 계정을 사용하는 모든 파드가 자동으로 AWS 리소스에 필요한 권한을 가질 수 있습니다.
aws configure로 AWS CLI 설정을 등록하는 것은 일반적으로 CLI나 AWS SDK에서 자격 증명을 사용하는 데 필요할 뿐, 파드에서 AWS 서비스에 접근하기 위해서는 IRSA 설정이 필요합니다. 하지만 EKS는 기본적으로 IRSA를 통해 파드가 쉽게 AWS 리소스에 접근할 수 있습니다.
Kops
Kops에는 IRSA와 같은 기능이 기본적으로 제공되지 않기 때문에, 파드가 AWS 서비스에 접근하려면 kube2iam 또는 KIAM 같은 도구가 필요합니다.
각 파드가 AWS 서비스에 접근하려면 IAM 역할을 개별적으로 설정해야 합니다. 이를 위해 kube2iam이나 KIAM을 설치하여, 각 파드에 적절한 IAM 역할을 매핑해주어야 합니다.
aws configure는 EC2 인스턴스 내에서만 작동하며, 파드에 IAM 역할을 부여하는 방식과는 다릅니다. 따라서 Kops에서는 aws configure로만 해결되지 않으며, kube2iam 또는 KIAM을 통해 파드에 IAM 역할을 매핑해줘야 합니다.
정리:
EKS: IRSA로 쉽게 파드별 IAM 역할을 매핑.
Kops: kube2iam 또는 KIAM을 설치해 파드에 하나하나 IAM 역할을 매핑해줘야 함. aws configure만으로는 해결되지 않음.
따라서, Kops에서는 kube2iam이나 KIAM이 반드시 필요합니다.
EKS에서는 aws configure로 자격 증명을 설정하고, IRSA를 사용하면 파드에 따로 설정을 하지 않아도 AWS 서비스에 접근할 수 있습니다.
Kops에서는 aws configure로 정보를 등록하더라도, 파드가 AWS 서비스에 접근하려면 별도의 인증이 필요합니다. 이 인증을 위해 kube2iam이나 KIAM 같은 도구가 필수적입니다.
kubectl logs pod/<cluster-autoscaler pod name> -n kube-system
Kops는 주로 유연성과 다양한 클라우드 제공업체를 지원하는 점에서 EKS와 차별화됩니다. 아래는 Kops의 주요 장점입니다:
- 멀티 클라우드 지원
Kops는 AWS뿐만 아니라 GCP, Azure, OpenStack 등 다양한 클라우드 플랫폼에 Kubernetes 클러스터를 배포할 수 있는 기능을 제공합니다.
EKS는 AWS에 종속적이지만, Kops는 여러 클라우드 환경에서 동일한 방식으로 Kubernetes 클러스터를 관리할 수 있어 하이브리드 클라우드나 멀티 클라우드 전략을 계획하는 조직에게 유리합니다. - 제어와 유연성
Kops는 사용자가 모든 클러스터 리소스를 직접 관리할 수 있습니다. EKS는 AWS가 관리형으로 제공되지만, Kops는 Kubernetes 클러스터의 모든 구성 요소를 사용자 정의할 수 있어 더 높은 제어권을 제공합니다.
이를 통해 네트워킹, 스토리지, 업그레이드 및 클러스터 관리 등에서 더 세밀하게 조정하고 싶을 때 유리합니다. - 오픈소스 커뮤니티
Kops는 오픈소스 프로젝트로, Kubernetes 커뮤니티의 지원을 받습니다. 따라서 다양한 기능 업데이트나 문제 해결에 커뮤니티의 힘을 빌릴 수 있으며, 오픈소스 프로젝트에 대한 기여를 통해 직접 참여할 수도 있습니다. - 비용 절감
Kops는 자체적으로 관리하는 Kubernetes 클러스터이므로, EKS 관리 비용(EKS 사용료 등)을 절감할 수 있습니다.
AWS 상에서 Kops 클러스터를 실행하는 경우 EC2 인스턴스나 S3 등의 비용만 지불하면 되므로, EKS의 추가 요금을 부담하지 않아도 됩니다. - 네트워크 및 인프라 구성의 자유
Kops는 네트워크 구성과 관련된 더 많은 옵션을 제공합니다. 예를 들어, CNI 플러그인 선택, 특정 네트워크 설정, 네트워킹 방식 등을 자유롭게 설정할 수 있습니다.
반면, EKS는 관리형 서비스로, AWS 네트워크 구조에 종속되는 부분이 있어, 유연한 구성이 제한적일 수 있습니다. - 클러스터 버전 관리 및 사용자 정의 설치
Kops는 Kubernetes의 다양한 버전을 선택할 수 있으며, 사용자가 원하는 대로 Kubernetes 버전, 구성 요소 등을 조정해 설치할 수 있습니다.
EKS는 기본적으로 AWS에서 제공하는 특정 버전을 사용해야 하지만, Kops는 최신 버전 또는 사용자가 원하는 특정 버전으로 커스터마이즈할 수 있습니다.
요약
EKS는 관리형 서비스로, 편리함과 AWS 통합 기능이 뛰어나고 운영 부담이 적습니다.
Kops는 다양한 클라우드 환경에서 유연하게 Kubernetes 클러스터를 구축하고, 세밀한 제어와 오픈소스 커뮤니티의 지원을 받을 수 있는 장점이 있습니다.
EKS와 Kops의 선택은 조직의 유연성 요구, 비용 구조, 클라우드 전략에 따라 달라질 수 있습니다.
