시작하며 서비스를 개발하다보면 외부 서비스에 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 컨테이너가 종료되도록 하곤했다. ...
시작하며 직접 구축하는 홈서버에 VM도 추가하고 싶어졌고 이전 글[1]과 마찬가지로 CLI로 VM을 띄워보고 싶었다. 이전 글에서는 VirtualBox를 이용했지만 이번에는 qemu라는 도구를 이용해 VM을 만들어보고자한다. qemu는 VM을 띄우는 도구들 중에서도 꽤나 로우한 레벨에 있으면서 손쉽게 다양한 아키텍쳐를 가상화해서 사용할 수 있게 해준다. 또한 CLI로 실행하는 프로그램이기에 VM을 손쉽게 띄워보고 싶은 나 같은 경우에 적합하다. 실습 환경 호스트 환경은 아래와 같다. 항목 정보 CPU amd64, 8 Core RAM 16GB Disk 256GB OS Ubuntu server 22.04 구성하고자하는 VM은 다음과 같다. ...
시작하며 홈서버를 직접 구성해보면서 실제 기기 개수가 많지 않아 좀 아쉬웠는데 최근에는 이를 VM으로 충당해볼까 싶은 생각이 들기도 했다. 갖고 있는 랩탑 하나에 여러 대의 VM을 띄우면 홈서버에서 좀 더 많은 수의 노드가 있는 것처럼 이용할 수 있지 않을까 싶어 VM을 띄워보기로 했다. 하지만 이번에는 단순히 GUI로 VM을 띄우는 것이 아니라 CLI로 VM을 띄우면서 LV(Logical Volume)을 이용해봤다. 해당 내용을 까먹을까봐 이 글을 통해 한 번 정리해본다. 실습 환경 호스트 환경은 아래와 같다. ...
시작하며 “반려 서버 키우기”라는 건전한 취미 생활을 본격적으로 시작하기 전에 그 사전 작업 중 하나로 Core DNS를 찍먹해보려한다. 현재 나의 홈랩 상황은 다음과 같다. (서버 및 장난감) 라즈베리파이 4대 (서버 및 장난감) 랩탑 1대 + 그 위의 VM 3대 (서버 관리용) PC 2대 핸드폰 2개 즉 나의 반려 서버는 8대, 반려 서버에 접속하는 장비는 4대(PC + 핸드폰) 정도라고 볼 수 있다. 기존에는 매번 사용하는 PC의 /etc/hosts 를 편집해서 도메인 네임을 이용하곤 했는데 한 대의 PC로만 접속하는 게 아니라 여러 장비로 서버에 접속하게 될 수 있다보니 매번 /etc/hosts를 편집하는 것이 그닥 유쾌하진 않았고, 심지어 모바일에서는 /etc/hosts 를 제어할 수 없어 IP로 직접 접근해야했다. ...
시작하며 저는 데브옵스 엔지니어로 현재(2022년 9월)의 회사에 입사한 후, 기존에 막연하게 궁금증을 가져왔던 Istio라는 제품을 주로 담당하게 됐습니다. 공식 문서와 릴리즈 노트 위주로 Istio를 공부하던 중 팀원분께 Istio in Action이라는 책을 추천받게 됐고, 이 책을 통해 조금 두루뭉실했던 이해와 삽질을 바탕으로 했던 판단들이 좀 더 분명해질 수 있었던 것 같습니다. 그 동안은 지루함으로 인해 책을 다소 멀리 하고 짧은 아티클들을 위주로 학습을 해온 반면 올해 제 목표 중 하나는 책을 통해 좀 더 개념을 잘 정리하고 깊이 있게 공부를 해나가는 것이었습니다. 이 책은 그런 저의 목표에 다행히 잘 부합해줬던 것 같고 정말 간단히 리뷰를 해보려합니다. ...
시작하며 시간은 정말 나이를 먹을 수록 빠르게 지나가는 것일까? 매번 지난 회고를 돌이켜보면 시간이 빠르게 지나갔다는 얘기로 시작하게 된 것 같다. 올해에도 역시나다. 시간이 참 빠른 것 같다. 이전 회고글과 같이 기술적으로 매력적인 신입이 되고자하는 회고라기보다는 이번 글은 회고라고 적기는 했으나 취준 과정 그리고 입사 이후에 대한 일기라고 볼 수도 있을 것 같다. 되돌아본 2022 크게 올 한해를 정리해보자면 다음과 같다. 2022.01~2022.02 | 당근마켓 플랫폼 서버 Golang 개발자 인턴으로 근무했다. 2022.03~2022.04 | 짧다면 짧은 시간이겠지만 취준생으로서 노력했다. 2022.03 | 고독한 취준 시기이고 이후에도 고독한 직장인이 되겠지만 그를 위해 취미 하나쯤은 갖고자 기타 레슨을 시작했다. 2022.04 | 취준을 마치고 홀로 🇺🇸미국여행을 다녀왔다. 향후 N년간은 겪어보지 못할 것 같다. 2022.05 | 행운이게도 고맙고 좋은 사람을 만났다. 2022.05 | 데브시스터즈에 데브옵스 엔지니어로 입사했다. 또 인생 첫 자취를 시작했다. 2022.07 | 회사에 적응 후 관심있던 istio 관련 업무를 주로 보고 있다. 2022.09 | 새로운 k8s와 클라우드 인프라 관리에 대한 큰 그림을 그려나가야할 때이다. 동료들과 종종 “진수님은 요즘은 잘 지내고 계신가요?” 이런 얘기를 나누게 될 때가 있다. 올해의 나는 항상 이렇게 대답하고 있다. “26년 인생 중 가장 행복한 한해를 보내고있다"고. ...
시작하며 데브옵스 엔지니어로 입사한 뒤 주로 맡고 있는 작업은 Istio 관련 작업이다. 평소 참 관심 있었던 분야이기도 하고 istio 뿐만 아니라 네트워크에 대해 개인적으로 정말 공부해보고싶었는데 덕분에 재미있게 공부하고 성장하며 근무하고 있는 것 같다. 😊 근데 요즘 들어 점점 단순히 ‘어떻게 저떻게 하니까 돌아는가네~ 오.. 나 istio 좀 파악한듯?ㅋㅋ’ 수준의 자세로는 트러블슈팅을 하거나 올바르게 설계하기가 쉽지 않은 경우들이 잦아졌다. 따라서 평소 궁금했던 내용 중 하나를 살짝 파헤쳐볼까한다. 나는 주로 istio ingress gateway와 관련된 작업을 많이 했었고 이 경우 Virtual Service는 항상 ingress gateway를 참조하도록 설정해왔다. 근데 istio를 처음 배울 때는 분명 ‘client 측에서 outbound handler 역할을 하는 Envoy 사이드카을 통해 알아서 우리가 의도하는 목적지를 찾아서 요청을 보낸다.’ 이런 식으로 배웠던 것 같은데 ‘왜 나는 Virtual Service를 이용할 때 항상 Gateway를 설정해줘야하는 것이었을까?’하는 궁금증이 생겼다. ...