노는 게 제일 좋아

정의Istio는 마이크로서비스 아키텍처(MSA)에서 서비스 간 통신을 관리하고, 보안, 관찰 가능성, 트래픽 관리를 지원하는 오픈소스 서비스 메쉬 플랫폼https://istio.io/latest/about/service-mesh/ 왜?Kubernetes 오브젝트만으로의 한계 트래픽 라우팅Service, Ingress버전별 분기, 트래픽 비율 분배 불가능보안 (mTLS)없음 (직접 구현 필요)Pod 간 통신 암호화가 기본 미지원인증/인가RBAC 위주서비스 간 세밀한 정책 적용 어려움트래픽 제어없음Retry, Timeout, Circuit Breaker 구현 어려움모니터링Metrics 수집 별도 구현세부 트래픽 분석 어려움정책 관리분산된 설정전역적으로 통제하기 어려움 Istio를 사용하면 가능한 기능들..

여기서 중요한 것은 ExternalDNS임 만약 public 이 필요 없다면 CoreDNS + Traefik 로 사용  정의external dns란 쿠버네티스 클러스터 내부 리소스를 외부 DNS 서비스와 연동하여 DNS 레코드를 자동으로 생성하고 관리할 수 있게 해주는 오픈소스  목적클러스터 내 서비스와 외부 도메인을 연결DNS 레코드 자동 생성 및 업데이트쿠버네티스의 Service 또는 Ingress 리소스를 기반으로 외부 DNS 제공자에 A 레코드 또는 TXT 레코드를 생성하고 삭제-> 주로 Ingress로 사용됨다양한 DNS 제공자와 연동, AWS Route53, Google Cloud DNS, Azure DNS 등 여러 퍼블릭 도메인 공급자와 호환 작동ExternalDNS를 배포하면 인그레스 리소..

왜?ArgoCD는 Kubernetes 애플리케이션 배포 및 관리의 복잡성을 해결 애플리케이션 배포의 일관성 부족→ 수동 배포나 스크립트 배포는 사람이 실수할 가능성이 높습니다.운영 환경의 실시간 상태 추적 어려움→ 어떤 리소스가 어디에 배포됐는지, 설정이 정확한지 파악하기 어려움.여러 환경 간 설정 차이 관리의 어려움→ dev/stage/prod 등에서 설정 드리프트 발생 가능성 gitops? GitOps란?Git을 단순 코드 저장소가 아닌, 배포 및 운영 설정의 단일 진실 원천(Single Source of Truth)으로 삼는 방식ArgoCD는 Git 리포지토리에 정의된 Kubernetes manifests (혹은 Helm chart 등)를 “원하는 상태”로 간주하고,Kubernetes 클러스터의 “..

왜? Helm은 Kubernetes 리소스를 패키징하고, 배포하고, 버전 관리하는 역할 Kubernetes에서는 Pod, Service, Deployment 등의 리소스를 YAML 파일로 정의 Helm은 이러한 YAML 템플릿을 묶어서 Chart라는 단위로 관리 Chart를 이용하면 복잡한 애플리케이션을 한 줄의 명령어로 설치 및 관리  -> chart는 세트메뉴해당 메뉴의 온전한 맛(서비스 제공) 을 느끼기 위해 필요한 모든 것(리소스)들이 준비 되어있음  Helm Chart를 구성하는 요소는?  Chart.yaml: 메타 정보 (이름, 버전 등)values.yaml: 설정 값 기본값 정의templates/: Kubernetes YAML 템플릿들이 위치하는 폴더charts/: 다른 의존 Chart..

25.03.19 뭔데?ArgoCD application을 모아서 관리하는 패턴을 app of apps패턴app of app패턴으로 구성된 application을 sync하면 여러 argoCD application을 생성생성된 application은 바라보는 git에 저장된 쿠버네티스 리소스를 배포하게 됨 https://blog.stackademic.com/simplifying-multi-application-management-with-argocds-app-of-apps-pattern-9e184a4973b5  왜?Application의 배포는 Git으로 관리되지 않음GitOps는 Argo CD를 움직이게 하는 핵심 개념으로, Argo CD가 관리하는 쿠버네티스의 배포에 관한 모든 사항이 Git에 기록된다..

OS는 Linux라고 하자. 어떻게 판단할 것이고로컬에 내가 모르는 프로세스가 있는지 확인ps: 현재 실행 중인 프로세스 확인 (의심스러운 프로세스, 백도어 프로그램 등)비정상적인 로그인 시도나 활동 조회(로그)/var/log/auth.log: 로그인 및 인증 관련 기록 확인 (ssh, su 등)/var/log/syslog 또는 /var/log/messages: 시스템 전반적인 로그 확인/var/log/secure: 보안 관련 로그 확인 (방화벽, 침입 탐지 시스템 등)내가 모르는 계정이 추가되었는지 확인  어떻게 대응할 것인가?

OSI 7 layer, Protocol, Cloud를 중심으로 설명해당 웹 서버가 AWS EKS 어느 파드에 떠있다고 생각하자 1단계: 브라우저에서 URL 입력사용자가 브라우저 주소창에 www.example.com을 입력브라우저는 HTTP/HTTPS를 통해 웹 서버에 요청을 보낼 준비를 함 2단계: 도메인 네임 해석 (DNS 요청, 응용 계층)브라우저는 먼저 www.example.com의 IP 주소를 알아야 하므로 DNS (Domain Name System) 조회를 수행브라우저 캐시, OS DNS 캐시, 로컬 hosts 파일을 먼저 확인캐시에 없으면 DNS 리졸버(보통 ISP의 DNS 서버)에 UDP 53 포트를 사용해 질의 2-1. 브라우저 및 OS 캐시 확인브라우저 캐시 확인브라우저는 최근 방문한 사..

[귀찮게하기/DevOps-SRE] - DevOps와 SRE 귀찮게 안하기 - DevOps 와 SRE[귀찮게하기/DevOps-SRE] - DevOps 귀찮게 안 하기 - DevOps가 하는 일 여기까지만 하고 나는 SRE와 DevOps를 구분하지 않으려고 한다. \SRE로 말하든 DevOps로 말하든-> DevOps나 SRE나 결국 서비스를 안정적으로 배포하는 데에 찬성하는 조직이자 역할이라고 생각한다.    SRE가 일하는 방법원칙을 가지고 일하게 됨 SRE 원칙서비스에 대한 명확한 정의가용성에 대한 정의, 목표장애 대응 계획모니터링효율성성능대기 시간장애에 대한 공동 책임  SRE 라고 하는 것은 거의 구글이 만들었다고 해도 될 만큼 Google 문화가 유명하다.   Google SRE 원칙자동화we w..

[귀찮게하기/DevOps-SRE] - DevOps 귀찮게 하기 - 하는 일 차이가 있는가? SRE란 Site Reliability Engineering 의 약자다. 대개 사람들이 말하는 SRE가 하는 일 이라면시스템, 서비스 및 제품에서 적절한 수준의 안정성을 지속적으로 달성할 수 있도록 지원하는 소프트웨어 엔지니어링 기술 애플리케이션을 빌드하고 유연하게 배포하고, 이를 모니터링할 수 있는 플랫폼이 필요한데, SRE의 역할은 이러한 플랫폼을 개발하고, 이 플랫폼 위에서 개발자들이 스스로 배포,운영을 하는 것이 목표  DevOps적용에 따라 개발팀은 속도와 변화(기능 추가 또는 개선)를, 운영팀은 안정성(대기시간, 스파이크)과 무중단을 중요시 하므로 이를 적절히 중재, 관리하기 위하여 SRE가 등장“ cl..

업무를 함으로써 추구하는 가치여러가지가 있지만 몇개만 추려보겠다.확장성신뢰성보안속도신속한 배포협업 확장성모든 곳에 자동화를 적용하고 온디맨드 기반으로 인프라와 애플리케이션을 확장할 수 있게함-> 새로운 애플리케이션을 개발한다면 그에 따른 인프라, 배포 등 여러가지를 자동화해서 바로 서빙신뢰성배포 품질, 안전한 서비스 환경, 프로덕션 환경과 동일한 환경에서의 테스트사용자 경험 개선을 위한 자동화 테스트 및 보안 테스트보안애자일 환경에서 자주 변경이 되어도 보안 검사는 적절하게 진행해야 함보안과 규정 준수 모범 사례를 자동화하고 모니터링하며 감지되면 자동화 방식으로 조치를 취함속도비즈니스 니즈를 기능으로 구성하고 신속하게 프로덕션에 반영할 수 있음결국 서비스의 시장 점유율을 높이거나 사용자 경험을 개선할 수..