Hi there 👋

Learning eBPF 스터디 새로운 기능을 커널에 추가하기 리눅스 커널은 3,000만줄의 거대한 코드의 복합체고 매우 복잡하다. 만약 우리가 커널에 새로운 기능이 필요하다면 커널에 대해 연구하고 새로운 기능을 개발하고, 수 많은 리뷰어로 부터 리뷰를 받아 메인 스트림에 패치를 추가해야 한다. 이 과정은 때때로 지지부진하며 많은 노력과 시간이 필요하다. 또한 이 기간동안 우리의 요구사항이 변경될 수도 있다. 커널에 기능 추가 대신 커널 모듈 만들기 커널과 같은 거대한 커뮤니티에 기여하는건 개발자로서 좋은 경험과 이력이지만 지지부진한 시간을 소비하기 싫다면 커널에 패치 만들기 말고 커널 모듈을 만들 수 있다....

Learning eBPF 스터디 eBPF는 개발자가 코드를 직접 커널 레이어에서 로드하고 커널의 동작을 변경할 수 있도록 허용하는 혁신적인 기술이다. eBPF는 고성능의 네트워킹, Observability, 보안도구에 이용할 수 있다. eBPF를 활용한 신규 애플리케이션을 만든다면 기존의 애플리케이션에 추가적인 수정이나 재설정등이 불필요한 이점이 있다. eBPF를 이용해서 다음이 것들을 할 수 있다. 시스템 측면에서(low level에서), 대부분의 성능측정 가시성을 제공하는 고성능의 네트워킹 분석 비정상 행위를 탐지하거나 예방 Note Moniroting: 시스템의 오류, 결함 또는 비정상적인 데이터들을 수집 및 가시화 Observability: 애플리케이션의 동작에 대한 세부적인 인사이트를 제공하기 위해 다양한 데이터(log, metric, audit)을 수집하고 분석하는 것을 의미하며 Micro-Service 아키텍쳐의 전반적인 구조적 결함을 찾는데 활용됨....

Rollout 사용자는 Application의 revision 업데이트를 rollout을 통해 수행할 수 있다. Deployment로 배치된 Application의 rollout예시는 다음과 같다. apiVersion:apps/v1kind:Deploymentmetadata:name:myapp-deploymentlabels:app:myapptype:front-endspec:template:metadata:name:myapp-podlabels:app:myapptype:front-endspec:containers:- name:nginx-containerimage:nginxreplicas:3selector:matchLabels:type:front-endRollout Strategy 새로운 Revision 배포방법들은 다양하다 Recrease 현재 버전의 Pod instance를 모두 삭제하고 새로운 Revision application으로 구성한다. 이 경우 이전 버전의 Pod instance들이 모두 삭제되고 새로운 Revision application이 배치될 때 까지 서비스 장애가 발생한다. Rolling Update 구 버전 Pod를 하나 삭제하고 Revision Pod를 새롭게 생성한다. 이 과정을 Pod의 개수만큼 수행하면 Pod가 없어 서비스를 제공하지 못하는 장애는 발생하지 않는다....

Monitor k8s의 Monitoring 지표들은 다양하다. 다음의 k8s는 다음과 같은 지표들을 확인할 수 있다. 노드 레벨의 통계: 클러스터를 구성하는 노드의 개수 및 상태 성능지표: CPU, 메모리 사용량, 디스크, 네트워크 I/O Pod 레벨지표: Pod의 개수, Pod의 자원 사용량 등 이처럼 다양한 성능지표들을 모니터링 할 수 있으나 중앙화된 관리와 해당 정보를 가공할 수 있는 솔루션이 필요하다. k8s에는 default로 탑재되는 모니터링 솔루션이 없지만 오픈소스로 공개된 다양한 솔루션들으 있으며 사용할 수 있다. 예를들면 Prometheus, Elastic Stack, Datadog, dynatrace등이 있다....

스케쥴러는 사용자가 정의한 리소스와 설정에 따라 Pod들을 배치한다. 스케쥴러는 Scheduling, Filtering, Scoring 과정을 거치며 Pod들을 배치한다. Scheduling(PrioritySort) Pod 생성 요청들을 queue삽입하며, PriorityClass에 기반한 정렬이 이루어짐 Filtering(NodeResourceFit) Pod가 배치되는 노드들을 filtering한다. Requests/Limits 설정에 따라 부족한 리소스를 갖는 노드들은 filter out된다. Scoring(NodeResourceFit) 배치 가능한 노드들에 대해 점수를 매긴다. 일반적으로 현재 요청된 Pod를 배치한 후 남은 리소스가 높을 수록 높은 점수를 받는다. Binding 선택된 노드에 Pod를 배치하는 단계....