보배로움

서비스 메시 (Service Mesh)? Mesh ? 이름 그대로의 역할 네트워크 전체에서 흩뿌려져 내부 동작을 손쉽게 제어 서비스 라우팅, 로드밸런싱, 텔레메트리에 대한 아이디어를 재구성 Kubernetes 이전? 관련된 기능을 특정 언어의 라이브러리로 제공했음 (물론 지금도 사용하는 곳도 많음) 무엇이 있었나? Scala - finagle Java - Netflix OSS (hystrix, ribbon), Spring cloud 만약 다른 언어에서 사용하고 싶다면? 사용할 수 없다. 해당 언어에서만 사용이 가능함. 해당 언어 애플리케이션에서 사용할 땐 의존성이 생기는 문제 단순히 import dependency가 아닌 애플리케이션 비즈니스 코드 내부로 깊게 침투해져 있는 경우가 많았다. 만약 이걸 때..

개요 서비스 (East-West) 파드 집합을 단일 유닛 또는 네트워크 서비스로 취급 로드밸런싱/라우팅. 서비스 검색 매커니즘. 레이어 3/4 매커니즘 인그레스 (North-South) 클러스터에서 실행되는 워크로드에 대한 진입점 세분화 된 트래픽 라우팅. 레이어7 로드밸런싱. 서비스 메시 더 진보된 라우팅, 보안, Observability 제공 East-West, North-South 지원 애플리케이션 소스코드 변경없이 Proxy/Sidecar를 이용한 통신 Kubernetes Service 여러 파드에서 걸쳐 트래픽을 로드밸런싱 하는 쿠버네티스의 핵심 API L3/L4 Layer load balancing -> TCP/IP, Port/IP 워크로드/파드는 대체 가능한 특성이기에 IP 대신 서비스를 이..

Secret에 대해 알아보기 전에 Secret이란 애플리케이션이 비밀로 유지하려는 데이터 더 쉽게 말하면 애플리케이션 서비스에서 필요한 비밀 데이터 ex) secret token, password, ... 다음과 같은 운영상의 문제를 고려해야 함 시크릿 순환 정책/키 (암호화) 순환 정책 시크릿의 순환 주기는 어떻게 결정할 것인가? 암호화 키의 순환 주기는 어떻게 결정할 것인가? 시크릿 저장 정책 시크릿 데이터를 저장할 때 어떤 요구사항을 충족해야 하는가? 격리된 하드웨어에 시크릿을 유지해야 하는가? 개선 계획 시크릿 또는 암호화 키가 손상되었을 때 어떻게 해결할 것인가? 애플리케이션에 영향주지 않고 계획 및 자동화를 실행할 수 있는가? 시크릿 관리를 어떤 레이어에서 제공할지 결정도 필요함 쿠버네티스 단..

개요 쿠버네티스 자체는 컨테이너를 생성, 시작, 중지하는 법을 알지 못한다. 대신 이런 작업을 컨테이너 런타임이라는 컴포넌트가 담당해 진행한다. 이 컨테이너 런타임에 대해 알아보자. 컨테이너 런타임을 간단하게 설명하면 다음과 같다. Linux: cgroups 및 namespace 같은 커널 기능을 이용하여 컨테이너 프로세스를 생성하는 녀석 Kubernetes: kubelet과 함께 동작하며 쿠버네티스 node에서 컨테이너를 생성 및 관리하는 녀석 그럼 2가지 의문점이 든다. 왜 쿠버네티스는 몰라야하는가? 명색의 컨테이너 기반 오케스트레이션인데 몰라도 되나? kubelet이 컨테이너를 관리한다고 했다. kubelet 내부에 컨테이너 런타임이 있다고 보면 되나? 이 의문점에 대해 답을 하기 위해 OCI, C..

M1 Mac 환경에서 podman 사용한 내용을 정리해보고자 한다. 다음에 까먹으면 다시 보기 위해서… 사실 docker 사용법을 안다면 거의 똑같다고 봐도 될 것 같다. 그냥 설치 및 초기설정 몇가지 방법만 다르다. 그렇기에 다 설치완료가 되면 아예 podman을 docker로 alias 설정해두고 사용하는 경우가 많은듯하다. podman 설치 brew 기반으로 설치했다. $ brew install podman $ brew install podman-compose # for docker-compose $ brew install podman-desktop # for docker d 초기 설정 Mac에서는 podman client/server로 나뉘어 동작하는 것으로 보인다. 이에 machine을 초기화,..

Pod spec 에는 restartPolicy 필드가 있다. Pod의 Container가 종료했을 때, 재시작 정책을 정의하는 필드이다. 3가지의 값을 허용한다. Always (default): Container들이 정상적으로 종료(zero exit code)되었더라도 재시작하는 정책. Container가 어떻게 종료되든 간에 무조건 구동 중이여야한다면 해당 옵션을 사용하는 것이 유용하다. OnFailure : Container가 비정상적으로 종료(non-zero exit code)하는 경우에만 재시작하는 정책. Pod가 특정 task를 수행하도록 설게되었고, 그 task가 완료(성공)되면 재시작하지 않는게 정상인 경우라면 해당 옵션을 사용하는 것이 유용하다. Never: Container의 exit c..

잘 모르면 몸이 고생한다고, Deployment replicas를 계속 변경하며 테스트 할 일이 있었는데 `kubectl edit` 으로 replicas를 변경해가며 사용했다. 근데 더 간단하게 CLI 상에서 replicas를 변경할 수 있는 `kubectl scale` 명령어가 있었다. # Scale a replica set named 'foo' to 3 kubectl scale --replicas=3 rs/foo # Scale a resource identified by type and name specified in "foo.yaml" to 3 kubectl scale --replicas=3 -f foo.yaml # If the deployment named mysql's current size i..

해당 글은 Kubernetes 공식문서 Garbage Collection를 토대로 작성한 글입니다. 조금 쉽게 표현하고자 추상적으로 표현한 부분들이 있는데, 자세한 내용은 공식문서를 참조해주세요. 쿠버네티스에서 일부 리소스들은 다른 특정 리소스로 하여금 만들어져 운영되는 경우가 있습니다. 다시 말해서, 특정 리소스가 일부 리소스의 owner 일 수 있고, 이러한 owner 리소스에 대해 일부 리소스가 dependents 리소스 일 수 있습니다. 즉, 리소스 간에 종속적인 관계가 존재할 수 있는 것입니다. 예를 들면, ReplicaSet 은 여러 Pod 들의 owner 라고 말할 수 있을 겁니다. 또한, 이 Pod 들은 ReplicaSet 에 대해 dependents 리소스라고 할 수 있겠죠. Owner ..