24년 10월 8일 AWS Operation Modernization Day(오프라인) - 역삼 센터필드

https://awsmodernization.splashthat.com/

 

잘못된 내용과 불분명하게 기술된 부분은 댓글 남겨주시면 같이 이야기 나눠보고 반영하도록 하겠습니다. 감사합니다. 

 

 

욕심 내지 말자, 10개중에 한개라도 제대로 주워먹자. 컨퍼런스 당일 날 정리해서 공유하자 ㅜ 오늘 할일을 내일로 미루지 말자 ㅜ

 

우리의 시간은 중요하니, 컨퍼런스에 소개되는 내용중 100%를 소화하면 좋겠지만, 최소한 몇 가지라도 얻어가는 것이 있으면, 그 날 하루는 성공적이라고 생각함.

기본적으로 컨퍼런스를 참석하는 이유는 

 

1. 우리 회사가 사용하고 있는 기술을 기술이 만들어진 본래의 “의도 및 철학"에 맞게 올바르게 잘 사용하고 있는지 다른 회사들의 사례나, 기술에 대한 deep한 내용을 살펴보면서 기술 자체에 대한 이해를 더 높이기 위해서

But, 이 과정에서 aws에서 소개하는 사례들은 가장 일반적인 사례들이고, 너무나 많은 고객사가 있기 때문에 명확하게 회사의 상황과 딱 들어맞는 환경은 찾기가 힘듬. 그래서 소개된 사례나 기술을 무분별하게 수용할 수도 없고, 수용해서도 안 됨.

 

 2. 새로운 기술 동향 파악  -> 우리가 해결하려는 문제를 조금 더 효율적으로 해결할 수 있는 부분이 없을까? 우리가 다른 회사의 IT 조직에 비해 뒤쳐지는 것은 아닐까? 뒤쳐지지 않기 위한 목적도 있음.

TLDR;

 

1. 최근 aws, k8s 컨퍼런스에서 항상 등장하는 키워드는 eBPF

 

기본적으로 AWS VPC CNI에는 기본적으로 커널단의 eBPF기능을 지원하지 않음. 최근에

Cilium, Opentelmetry(Observability 기능에 초점) 등에서 eBPF 기능을 지원해서 해당 기능이 커널 레벨에서 동작하며, iptables와 같은 전통적인 패킷 처리 방식 대신 네트워크 트래픽을 제어해서, 여러 계층을 거쳐서 발생할 수 있는 네트워크의 오버헤드를 최소화해서 각광 받고 있음.

 

 

cf) 

• https://ebpf.io/what-is-ebpf/
• https://hyeyoo.com/133
• https://github.com/open-telemetry/opentelemetry-network
• https://aws.amazon.com/ko/blogs/korea/amazon-vpc-cni-now-supports-kubernetes-network-policies/  # cilium CNI 에서 기본적으로 제공하던 기능 중의 하나임(네트워크 policy)

(아쉬운 점 해당 정책은 ipblock Ns, pod 단위로만 설정, caliocni 는 전역으로 설정 가능)

 

1. Ingress의 신규 기능 중단(대체 리소스는 Gateway API  (API Gateway와 헷갈리면 안됨) 

• Ingress 의 신규 기능 개발은 중단되었고 -> Ingress의 대체 리소스로 Gateway API가 점진적으로 대체가 진행되고 있는중. 하지만 eks 환경에서 온전한 Gateway API 구현을 사용하기위해서는 amazon vpc Lattice가 필요하고(명백한 한계점). cloud-controller-manager 부분에서 아직 완벽하게 Gateway API 기능을 지원하지 않으므로, 우선은 Ingress를 사용해서 클러스터를 구성하는것을 추천함.

->  Gateway API에 대한 관심은 가지고, Ingress -> Gateway API migration 할 가능성은 염두해둬야 할 듯

 

cf) 

 

https://kubernetes.io/docs/concepts/services-networking/ingress/

 

https://kubernetes.io/blog/2023/10/25/introducing-ingress2gateway/

1. IRSA -> Pod Identity (향후 신규 클러스터 구축 및 버전 업그레이드 시 반드시 고려해야 함) 

 

Amazon EKS Pod Identity를 통한 경험 간소화
2019년에 서비스 계정에 대한 IAM 역할(IRSA)을 도입했습니다. IRSA를 사용하면 IAM 역할을 Kubernetes 서비스 계정에 연결할 수 있습니다. 이를 통해 포드에 필요한 권한만 부여하여 최소 권한 원칙을 구현할 수 있습니다. 이 접근 방식은 IAM의 포드 우선순위를 지정하고 개발자가 AWS 서비스에 대한 최소 권한 액세스를 지원하는 세분화된 권한으로 애플리케이션을 구성하는 데 도움이 됩니다.

이제 Amazon EKS Pod Identity를 사용하면 Kubernetes Identity에 AWS 권한을 부여하는 작업을 더 쉽게 구성하고 자동화할 수 있습니다. 클러스터 관리자는 더 이상 모든 AWS 리소스에 대한 애플리케이션을 인증하기 위해 Amazon EKS와 IAM 서비스 사이를 전환할 필요가 없습니다.

Amazon EKS Pod Identity 사용을 시작하기 위한 전체 워크플로는 몇 가지 간단한 단계로 요약할 수 있습니다.

• 1단계: 애플리케이션에 필요한 권한이 있는 IAM 역할을 생성하고 신뢰 정책에서 pods.eks.amazonaws.com을 서비스 주체로 지정합니다.
• 2단계: Amazon EKS 콘솔 또는 AWS Command Line Interface(AWS CLI)를 사용하여 Amazon EKS Pod Identity Agent 추가 기능을 설치합니다.
• 3단계: Amazon EKS 콘솔, API 또는 AWS CLI에서 직접 서비스 계정에 역할을 매핑합니다.

작업이 완료되면 해당 서비스 계정을 사용하는 모든 새 포드가 자동으로 IAM 자격 증명을 수신하도록 구성됩니다.

cf)
- https://techblog.uplus.co.kr/eks-pod-identity-addon-poc-3326b6adb23e

- https://aws.amazon.com/ko/blogs/korea/amazon-eks-pod-identity-simplifies-iam-permissions-for-applications-on-amazon-eks-clusters/

• 심화) 

 

ec2 - eks - 접근제어 매핑

ec2 -NACL   security group 

eks - network policy(NACL), pod security group (security group)

 

 

# 잘 안 알려진 기능

 

ENIConfig  -  보안 심의 받을때 내가 원하는 ip address pool을 정확하게 매핑가능. 더 나아가서 특정 az에도 binding 할 수 있다.  # eks 특성상 동적으로 매핑되는 부분 보완할 수 있음
https://aws.github.io/aws-eks-best-practices/networking/custom-networking/

Custom Networking - EKS Best Practices Guides

 

 

Introducing security groups for pods

 

https://brunch.co.kr/@growthminder/103

Pod Security Group 동작 원리

 

 

+ 심화

https://aws.github.io/SigV4-for-AWS-IoT-embedded-sdk/v1.2.0/

 

 

 

정책 관리 도구

https://devocean.sk.com/blog/techBoardDetail.do?ID=166075&boardType=techBlog

 

• Kyverno 

 

리소스 배포를 할때 회사가 정한 룰을 지켰는지 사전에 검증 가능함

 

어떤 부분이 문제인지 메시지도 띄워줄 수 있고, 오픈소스로 다양한 use case가 많다.

https://ddii.dev/kubernetes/kyverno/

kyverno를 활용한 Kubernetes 정책 엔진 적용 | Cloud Catalyst

 

 

• PSA/PSS(Pod Security Admission / Standard) 

PSA는 PSS를 사용하여 전체 적용하도록 하는 방식으로 단순하게 3가지 모드만 지정할 수 있는 단순한 기능이다.

따라서 라벨 지정을 강제하는 정책을 만들수가 없으며 k8s 진영에서 정의한 기본(baseline), 최소권한(restricted), 권한허용(previledged) 중 하나를 전체적으로 적용하는 것만 가능하다.  # baseline 정도 쓰는 것을 추천함

 

 

Amazon GuardDuty란?​

매니지드 형 위협 검출 서비스인Amazon GuardDuty는 여러가지 로그를 감시하고 기계학습으로 위협을 검출합니다. ‘어느새 자사AWS환경이 공격을 받아 큰 피해로 이어져버렸다’등의 상태를 피하기 위해 유효하고 AWS의 베스트프렉티스에도 모든AWS계정에서 Amazon GuardDuty를 유효화하는 것이 추장되고 있습니다.

구체적으로는 유저의 조작이나 통신 등의 로그를 계속적으로 모니터링해서 수상한 서버와의 통신, 부정 액세스 등 ‘악의적인’동작을 기계학습을 가지고 검출합니다.

2022년7월에는 신기능이 추가되어EC2인스턴스의 멀웨어 스캔이 가능해졌습니다. C＆C서버와의 통신 등 멀웨어 감염이 의심되는 거동이 검출되었을 때 EC2인스턴스의 디스크 영역으로 이용하는 [Amazon EBS]내의 파일을 스캔하여 수상한 파일을 특정합니다.

다만, Amazon GuardDuty가 진행하는 것은 [검출]까지. 멀웨어를 포함하는 모든 위협에 관해 검출 후의 격리나 통신 블록은 이용자 자신이 판단해서 별도 대응할 필요가 있어 주의가 필요합니다.

[출처] ’Amazon GuardDuty’란? 초보자를 위해 해석!|작성자 클래스메소드코리아

 

 

세션 소개

1.  EMR on EKS overview

2. Cilium을 활용한 Amazon EKS 네트워크 가시성 및 보안 강화

3. Amazon EKS에서 Kubernetes Gateway API 도입: 인그레스 트래픽 관리 현대화

 

 

 

================================================================================

1. EMR on EKS overview

 

• Data on EKS

 

cf) https://aws.github.io/aws-emr-containers-best-practices/submit-applications/docs/spark/pyspark/

• 신속한 job 실행
• EMR on EKS: Spark, Flink만 가능

 

1. spark

 

• Drive Process, Executor Process -> Pod로 변환
• Shuffle Data I/O, Network I/O 최소화

1. EMR on EKS concept

 

 

• aws emr-containers start-job-run sparkSubmitParameters

cf) https://aws.amazon.com/ko/blogs/tech/amazon-eks-spark-submission-comparison/

• job-runner(k8s job으로 뜸) - 차이점, spark-driver
• driver -> executor -> task 

 

1. BestPractice  # 핵심 Shuffling 할 때, I/O, 네트워크 연산 최소화 하는 것이 성능 향상의 핵심

• AWS는 AZ간 비용부과함 (AZ 이동 최소화가 좋음)

• Pod Scheduling - Driver vs Executor
• Spot Instance 사용시 Shuffle files를 PVC에 저장 (PVC 재연산 방지)
• Local Directory - tmpfs

cf) https://ko.wikipedia.org/wiki/Tmpfs

 

• 자원 경합(Race Condition) 방지 하기 위해 Custom Scheduler 사용하기 - Gang Scheduler (YuniKorn(Apache), VOLCANO(CNCF))

https://docs.aws.amazon.com/ko_kr/emr/latest/EMR-on-EKS-DevelopmentGuide/tutorial-volcano.html

 

 

 

 

 

1. Apache Spark
2. EMR on EKS 동작 방식

====================================================

2. Cilium을 활용한 Amazon EKS 네트워크 가시성 및 보안 강화

 

 

 

 

 

 

 

 

 

 

 

 

 

 

====================================================================================

 

 

3. Amazon EKS에서 Kubernetes Gateway API 도입: 인그레스 트래픽 관리 현대화

- 클라이언트 사이드 / 서버사이드

- 중앙화 / 분산 구조

- L4 / L7 정확한 이해

 

 

 

 

 

 

 

 

 

 

 

 

 

 

그래서 짜잔 gateway api 등장

 

 

 

 

eks  인증/인가 부분 추가 예정