시작하며 서비스를 개발하다보면 외부 서비스에 HTTPS로 요청을 보내는 경우가 생길 수 있다. Istio를 사용하는 경우, Service registry에 등록되어있지 않은 host를 바탕으로한 요청은 기본적으로 Passthrough라고하는 Cluster로 인식되며 Passthrough 클러스터는 단순한 TCP proxy로 동작한다. 즉, 해당 TCP 패킷에 대해 아무런 부가기능을 수행해주지 않고 그냥 패킷을 전달할 뿐이다. 이 경우 L7인 HTTPS를 바탕으로한 요청에 대해 Istio는 L4인 TCP 수준의 메트릭 밖에 기록하지 못하며, TCP 메트릭 또한 정보가 매우 빈약하게 된다. Service registry - Service Mesh가 인지하고 있는 Service 정보를 모아둔 것을 의미 (참고: Istio 공식 문서) ...
시작하며 K8s에서 Istio를 통해 서비스 메쉬를 구현하는 경우, Istio는 알아서 Pod가 사용하는 ServiceAccount에 대한 인증서를 발급해주고 이를 바탕으로 메쉬 내부에서는 mTLS를 이용한 시큐어한 통신이 가능하다. 하지만 메쉬 내부에서 뿐만 아니라 메쉬 외부와도 mTLS로 시큐어하게 통신하고 싶은 경우에는 어떨까? 예를 들어 내 서비스에 VPN 없이 퍼블릭하게 인터넷으로 접근은 가능하지만 해당 서비스를 나만 이용하고 싶은 경우, 내 디바이스에 설치된 인증서를 이용해 내 서버와 mTLS로 통신을 하려면 어떻게 해야할까? 다음 몇 가지 요소들만으로도 Istio를 통해 손쉽게 Ingress gateway단에서 클라이언트(나를 비롯한 유저들)과 mTLS 통신을 지원할 수 있다. ...
시작하며 인증서 방식의 인증 및 암호화는 보안성이 좋고, 경우에 따라 편리하기까지 하다. 경우에 따라인 이유는 인증서 관리가 수작업으로 하기는 참 번거로운 작업이지만 또한 자동화하기 쉬운 작업이기 때문이다. Istio와 같은 서비스 메쉬 솔루션을 이용하면 인증서를 통해 손쉽게 TLS 혹은 mTLS 통신이 가능하다. 회사에서 업무를 보다보면 애플리케이션 컨테이너가 데이터베이스를 이용할 때 mTLS를 통해 인증과 암호화를 하기 위해 initContainer에서 인증서 관련해 별도의 작업을 해줘야하는 경우가 있었다. initContainer 뿐만 아니라 volume과 volumeMount 설정, 데이터베이스 접속을 위한 URL 환경변수 등등 다양한 설정이 복잡해지면서 Helm chart를 수정할 때 실수를 범하게 되는 경우가 종종 있었다. ...
시작하며 쿠버네티스에서 서비스메쉬 솔루션으로 Istio를 운영하다보면 Pod가 종료될 때 커넥션이 비정상적으로 종료되는 경우가 종종 발생할 수 있다. Pod가 종료되는 경우는 kubectl delete를 통해 직접 Pod를 죽이는 경우, 롤링 업데이트나 스케일 인을 진행하는 경우 등 다양하다. 커넥션이 비정상적으로 종료되는 이유는 무엇일까? 다양한 경우의 수가 있을 수 있겠지만 아마 대부분 사이드카로 뜨는 istio-proxy 컨테이너가 애플리케이션 컨테이너보다 먼저 종료되는 것이 원인일 것이라고 생각한다. v1.12 이전의 Istio를 이용하던 사람들은 다음과 같이 istio-proxy 컨테이너에 preStop 설정을 추가해 해당 컨테이너에 커넥션이 모두 종료된 후 istio-proxy 컨테이너가 종료되도록 하곤했다. ...
시작하며 저는 데브옵스 엔지니어로 현재(2022년 9월)의 회사에 입사한 후, 기존에 막연하게 궁금증을 가져왔던 Istio라는 제품을 주로 담당하게 됐습니다. 공식 문서와 릴리즈 노트 위주로 Istio를 공부하던 중 팀원분께 Istio in Action이라는 책을 추천받게 됐고, 이 책을 통해 조금 두루뭉실했던 이해와 삽질을 바탕으로 했던 판단들이 좀 더 분명해질 수 있었던 것 같습니다. 그 동안은 지루함으로 인해 책을 다소 멀리 하고 짧은 아티클들을 위주로 학습을 해온 반면 올해 제 목표 중 하나는 책을 통해 좀 더 개념을 잘 정리하고 깊이 있게 공부를 해나가는 것이었습니다. 이 책은 그런 저의 목표에 다행히 잘 부합해줬던 것 같고 정말 간단히 리뷰를 해보려합니다. ...
시작하며 데브옵스 엔지니어로 입사한 뒤 주로 맡고 있는 작업은 Istio 관련 작업이다. 평소 참 관심 있었던 분야이기도 하고 istio 뿐만 아니라 네트워크에 대해 개인적으로 정말 공부해보고싶었는데 덕분에 재미있게 공부하고 성장하며 근무하고 있는 것 같다. 😊 근데 요즘 들어 점점 단순히 ‘어떻게 저떻게 하니까 돌아는가네~ 오.. 나 istio 좀 파악한듯?ㅋㅋ’ 수준의 자세로는 트러블슈팅을 하거나 올바르게 설계하기가 쉽지 않은 경우들이 잦아졌다. 따라서 평소 궁금했던 내용 중 하나를 살짝 파헤쳐볼까한다. 나는 주로 istio ingress gateway와 관련된 작업을 많이 했었고 이 경우 Virtual Service는 항상 ingress gateway를 참조하도록 설정해왔다. 근데 istio를 처음 배울 때는 분명 ‘client 측에서 outbound handler 역할을 하는 Envoy 사이드카을 통해 알아서 우리가 의도하는 목적지를 찾아서 요청을 보낸다.’ 이런 식으로 배웠던 것 같은데 ‘왜 나는 Virtual Service를 이용할 때 항상 Gateway를 설정해줘야하는 것이었을까?’하는 궁금증이 생겼다. ...
시작하며 요즘 istio를 공부하던 중 istio가 변화해온 과정에 대해서도 흥미가 생겨 지난 버전들의 릴리즈 노트들도 읽어보고 있습니다. 그러던 중 현 시점(2022년 7월)에는 이미 공식적인 End of Life가 지난 2021년 3월 처음 릴리즈된 istio 1.10의 릴리즈 노트를 보다가 재미있는 점을 하나 발견할 수 있었는데요. 바로 envoy proxy가 eth0에 대한 요청을 넘겨주는 container의 network interface가 lo 에서 eth0 로 변경되었다는 점입니다. 네트워크에 대해, 그 중에서도 특히 네트워크 인터페이스에 대해 잘 몰랐던 때에는 이 변경사항에 그닥 관심이 안 갔을 것 같은데 최근 네트워크 인터페이스에 대해 공부를 해서인지 이 변경사항에 관심이 갔습니다. ...
시작하며 올해에는 많은 변화가 있었다! 💼 데브옵스 엔지니어로 회사를 가게 됐고 아주 만족 중이다! 🏠 회사의 좋은 보상, 복지에 힘입어 생애 첫 자취를 하게 됐다. 💻 네트워크나 리눅스, 보안 등 딥한 영역에 좀 더 관심을 갖게 됐다. 🎸 기타를 꾸준히 다니고 있다. 그런 변화들 속에서 자취방에 인터넷 설치를 하게 됐는데 클로바 AI 스피커를 공짜로 주더라. 본가에 있을 때도 쓰긴 했는데 딱히 관심 없다가 직접 클로바 앱을 깔아서 이것저것 써보니 ‘전보다 재밌네..? ㅎㅎ’ 싶었고, ‘아니 이거 직접 만들지는 못하나’하는 생각이 들던 참에 “스킬 스토어”라는 게 눈에 띄었다. 스킬 스토어에는 개별 개발사들이 개발한 자기네 기능들이 소개되어있었다. ...