DevOps Engineer

8. 관찰가능성 Observability : Visualizing network behavior with Grafana, Jaeger, and KialiThis chapter covers그라파나를 사용해 메트릭을 시각적으로 관찰하기 Using Grafana to observe metrics visually예거를 사용한 분산 트레이싱 계측하기 Distributed tracing instrumentation with Jaeger키알리로 네트워크 호출 그래프 시각화하기 Visualizing the network call graph with Kiali들어가며이번 장에서는 앞 장에서 구축한 기반을 바탕으로 몇 가지 도구를 사용해 서비스 메시의 데이터를 시각화해본다.이스티오의 데이터 플레인과 컨트롤 플레인 구성 요..

7. 관찰가능성 Observability: Understanding the behavior of your servicesThis chapter covers기본적인 요청 수준 메트릭 수집하기 Collecting basic request-level metrics이스티오의 서비스 간 표준 메트릭 이해하기 Understanding Istio’s standard service-to-service metrics프로메테우스로 워크로드 및 컨트롤 플레인 메트릭 긁어오기 Using Prometheus to scrape workload and control-plane metrics이스티오에 프로메테우스에서 추적할 새 메트릭 추가하기 Adding new metrics in Istio to track in Prometheus..

6장 Resilience: Solving application networking challengesThis chapter covers회복탄력성의 중요성 이해 Understanding the importance of resilience클라이언트 측 로드 밸런싱 활용 Leveraging client-side load balancing요청 시간 초과 및 재시도 구현 Implementing request timeouts and retries회로 차단 및 연결 풀링 Circuit breaking and connection pooling마이그레이션 Migrating from application libraries used for resilience 들어가며4장에서 다룬 이스티오 인그레스 게이트웨이를 거쳐 클러스..

5장 Traffic control: Fine-grained traffic routing이번 장의 목표Traffic routing basicsShifting traffic during a new releaseMirroring traffic to reduce the risk of a new releaseControlling traffic as it leaves a cluster 들어가며 : 트래픽 세부 라우팅 필요 설명이전 장에서 우리는 트래픽을 클러스터로 가져오는 방법과 이를 위해 고려해야 할 사항들을 살펴보았습니다.요청이 클러스터에 들어오면, 요청을 처리하기 위해 적절한 서비스로 어떻게 라우팅되나요?클러스터 내에 있는 서비스는 같은 클러스터 내 또는 클러스터 외부에 있는 다른 서비스와 어떻게 통신하나요?..

4.2.3 Overall view of traffic flow 전체적인 트래픽 흐름 개요이스티오 게이트웨이 리소스는 서비스 메시 클러스터의 엣지에서 리스닝하고자 하는 포트, 프로토콜, 가상 호스트를 정의한다.VirtualService 리소스는 에지에서 허용된 트래픽이 가야 할 곳을 정의한다. 4.2.4 Istio ingress gateway vs. Kubernetes Ingress쿠버네티스를 실행할 때 ‘왜 이스티오는 그냥 쿠버네티스 인그레스 v1 리소스를 인그레스로 지정하지 않는가?’ 라는 의문이 생길 수 있다. 이스티오는 쿠버네티스 인그레스 v1 리소스를 지원하지만, 쿠버네티스 인그레스 v1 사양에는 상당한 한계가 있다.쿠버네티스 인그레스 v1 의 사양이 HTTP 워크로드에 맞춰져 매우 단순하다는 점..

개요CloudNet에서 주관하는 istio(Istio Hands-on Study) 1기 스터디 2주차 글이다. 아래의 글은 스터디의 내용을 기반으로 작성했으니 많은 관심 부탁 드린다. CloudNet@ Blog 에서 스터디 관련 글 및 모집 글을 확인 가능하다. 3장 Istio’s data plane: Envoy Proxy이번 장은 아래와 같은 목표가 있다.Understanding the standalone Envoy proxy and how it contributes to Istio : Istio 에 Envoy 동작 이해Exploring how Envoy’s capabilities are core to a service mesh like Istio : Envoy 기능 알아보기Configuring En..

시작하기 전1주차 시작하고 나서지만 간단히 시작한 소감을 적어보려고 한다.대기업이나 대규모 트래픽을 가진 기업들은 꼭 Istio를 요구 사항으로 넣는 것으로 보았다. 또한 내부 트래픽을 간단하게 전달하고 보안적 요소가 좋다는 이야기를 들은 적이 있었어서 공부해보고 싶은 주제였기도 하고, 사실 완벽하게 이 툴에 대한 이해도를 높이는 것보다 (이렇게 되려면 실무에서 사용해야 하는데 사용하고 있지 않고, 사용할 것 같지 않다) 직접 마주해보고 싶은 느낌이 강했다.항상 정리의 글은 파란색 글씨인 인용문으로 달고자 하니 참고 바란다. 파란 글씨와 본글을 번갈아 읽으면 더 이해가 잘될것! 인용문은 링크도 있으니 참고 바란다! 1장 서비스 메시 소개하기배경클라우드 플랫폼이나 컨테이너 같은 신기술을 더 빠르게 활용하..

예전에 작성했던 블로그 글들은 다 특정 서식을 만들어 놓고 그 서식대로 작성하려고 노력했었다. 근데 서식만을 맞추다 보니 서식은 맞지만 뭔가 퀄리티가 떨어지는 것 같아 아래와 같이 서식도 변경하고 조건도 변경하여 블로그 글을 작성해보고자 한다. 서식과 조건개요에는 내가 왜 이 글을 작성하게 되었는지에 대한 설명을 담으려고 한다. 그래야 글을 읽는 독자로 하여금 더 정확한 상황에서의 사용을 할 수 있을 것 같아서이다.본문은 이전과 거의 비슷하게 진행될 것 같다. 제목을 대주제로 두고 해당 제목에 대한 소주제를 분류해 해당 소주제를 기반으로 작성할 것이다. 그러나 내용을 작성하는 과정에서 WHY, WHAT, HOW를 중점으로 작성하여 읽는 이로 하여금 더 명쾌하고 올바른 설명이 될 수 있도록 할 것이다.후기..

올해 2024는 참 스스로의 질책을 많이 한 시기였던 것 같다.프로젝트도 이렇다 할만큼 제대로된 성과를 얻지도 못했고, 회사 내외부적으로 얻은 지식이 되돌아보니 많이 없던것 같다.  한거는 꽤 많은 것 같은데 말이다... 그래서 분기 별로 회고를 꼭 하려고 했었는데 그 마저도 하지 않았던 것 같다. 동년배거나 동년차인 잘하는 엔지니어들과 비교하며 스스로 위축되기도 했던 것 같다.계속 상황을 탓하게 된 것은 아닌지 왜 노력하지 않았는지 분석하지 않고 당장 놓여있는 업무와 왜 하는지도 모르는 것들을 급급히 처리하기 바빴던 것 같다. 굉장히 반성하는 부분이다.업무를 할때 왜 하는지가 가장 중요하면서 정작 나한테는 그 부분을 신경쓰지 않았으니 말이다. 뭐 그래도 CKA나 SOA 자격증 취득하면서 넓은 범위의 지..