저 높은 곳으로 저 높은 곳으로

Ingress Ingress는 클러스터 외부에서 클러스터 내부 Service로 HTTP와 HTTPS 경로를 열어준다. Ingress resource에 규칙을 정하여 트래픽을 컨트롤할 수 있다(Load Balance). Ingress는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL/TLS 종료, 이름 기반의 가상 호스팅 기능을 구성할 수 있다. Ingress Controller는 일반적으로 로드 밸런서(ex. Nginx)를 사용해서 Ingress를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. Ingress는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보..

서비스 Service는 동일한 기능을 제공하는 Pod 그룹에 대한 안정적인 접근 방식을 제공한다. Service는 클라이언트가 Pod 그룹을 네트워크에서 사용할 수 있도록 해준다. 서비스 타입 ClusterIP Service에 내부 IP를 할당하여 클러스터 내부에서만 접근할 수 있게 한다. NodePort ClusterIP에 기반하며, 각 Node의 지정된 Port를 통해 외부에서 Service에 접근할 수 있게 한다. Ports port targetPort nodePort NodePort 서비스 생성 YAML apiVersion: v1 kind: Service metadata: name: my-service spec: type: NodePort selector: app: MyApp ports: - po..

Understand Deployments and how to perform rolling updates Use Kubernetes primitives to implement common deployment strategies (e.g. blue/green or canary) Deployment Create kubectl create -f Get kubectl get deployments Describe kubectl describe deployment Update Apply file kubectl apply -f Set image kubectl set image deployment/ = Status Status kubectl rollout status deployment/ History kubectl r..

6장에서 설명한 메시지와 인터페이스 원칙에 따라 의도를 드러내도록 인터페이스를 다듬고 명령과 쿼리를 분리했다고 하더라도 명령으로 인해 발생하는 부수 효과를 명확하게 표현하는 데는 한계가 있다 여기서 말하고 싶은 것은 인터페이스만으로는 객체의 행동에 관한 다양한 관점을 전달하기 어렵다는 것이다 우리에게 필요한 것은 명령에 부수 효과를 쉽고 명확하게 표현 할 수 있는 커뮤니케이션 수단이다. 이럴 때 필요한 것이 계약에 의한 설계이다 계약에 의한 설계를 사용하면 협력에 필요한 다양한 제약과 부수 효과를 명시적으로 정의하고 문서와 할 수 있다 클라이언트 개발자는 오퍼레이션의 구현을 살펴 보지 않더라도 객체 사용 법을 쉽게 이해할 수 있다 계약은 실행 가능하기 때문에 구현 의 동기화돼 있는지 여부를 런타임에 검증..

디자인 패턴: 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 설계의 묶음이다. 프레임워크: 설계와 코드를 함께 재사용하기 위한 것 프레임워크는 애플리케이션의 아키텍처를 구현 코드의 형태로 제공한다. 프레임워크가 제공하는 아키텍처가 요구사항에 적합하다면 견고한 구현 코드를 쉽고 빠르게 재사용할 수 있다. 프레임워크는 각 애플리케이션 요구에 따라 적절하게 커스터마이징 할 수 있는 확장 포인트를 제공한다. 디자인 패턴과 프레임워크 모두 일관성 있는 협력과 관련이 있다. 디자인 패턴은 특정한 변경을 일관성 있게 다룰 수 있는 협력 템플릿을 제공한다. 프레임워크는 특정한 변경을 일관성 있게 다룰 수 있는 확장 가능한 코드 템플릿을 제공한다. 01 디자인 패턴과 설계 재사용 소프트웨..

객체지향 프로그래밍의 장점 중 하나는 코드를 재사용하기 용이하다는 것이다. 전통적인 패러다임에서 코드의 재사용은 코드를 복사 후 수정하는 것이다. 객체지향에서 코드는 일반적으로 클래스 안에 작성되기 때문에 객체지향에서 클래스를 재사용하기 위한 전통적인 방법은 새로운 클래스를 추가하는 것이다. 이번 장에서는 클래스를 재사용하기 위해 새로운 클래스를 추가하는 가장 대표적인 기법인 상속에 대해서 살펴본다. 상속 재사용 관점에서 상속이란 클래스 안에 정의된 인스턴스 변수와 메서드를 자동으로 새로운 클래스에 추가하는 구현 기법이다. 합성 새로운 클래스의 인스턴스 안에 기존 클래스의 인스턴스를 포함시키는 방법 코드를 재사용하려는 강력한 동기 이면에는 중복된 코드를 제거하려는 욕망이 숨어 있다. 중복 코드가 초래하는..

책임에 초점을 맞춰서 설계할 때 가장 큰 어려움은 어떤 객체에 어떤 책임을 할당할지를 결정하기 쉽지 않다는 것이다. 01 책임 주도 설계를 향해 데이터보다 행동을 먼저 결정하라 책임 중심 설계에서는 "이 객체가 수행해야 하는 책임은 무엇인가"를 결정한 후에 "이 책임을 수행하는 데 필요한 데이터(상태)는 무엇인가"를 결정한다. 협력이라는 문맥 안에서 책임을 결정하라 협력에 적합한 책임이란 메시지 수신자가 아니라 메시지 전송자에게 적합한 책임을 의미한다. 협력에 적합한 책임을 할당하기 위해서는 메시지를 결정한 후에 객체를 선택해야 한다. 메시지를 수신하기로 결정된 객체는 메시지를 처리할 책임을 할당 받게 된다. 협력이라는 문맥 안에서 메시지에 집중하는 책임 중심 설계는 캡슐화의 원리를 지키기가 훨씬 쉬워진..

프로젝트의 성패를 좌우하는 핵심 Topic 49 실용주의 팀 L 그룹에서 스토펠은 여섯 명의 일류 프로그래머를 감독한다. 이는 말하자면 고양이 떼를 모는 일에 비할 만한 도전적인 관리 업무다. 프로그래머는 고양이 같은 면이 있다. 호기심이 많고 제멋대로이며, 고집이 세고, 독립적인 데다, 가끔은 인터넷에서 숭배를 받기도 한다. 이제까지 우리는 개인이 더 나은 프로그래머가 되게끔 도와주는 실용주의 기법들을 살펴보았다. 이런 방법이 팀에도 적용될까? 제멋대로이고 독립적인 사람들이 모인 팀에서도? 답은 명쾌한 "그렇다!"이다. 실용주의 팀은 작다. 구성원이 대략 10~12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다. 모두가 서로 잘 알고, 신뢰하며, 의존해야 한다. Tip 84 작고 안정..