kubernetes pod cluster에 대한 service discovery 및 loadbalance, dns 서비스를 제공한다. 따라서, kubernetes의 실제 서비스는 Service Object로부터 시작된다고 볼 수 있다. 보통 실제 서비스를 제공할 때에는 application을 여러 개의 Pod으로 배포하면서, 이를 로드밸런스를 이용하여 하나의 IP와 포트를 묶어서 서비스를 제공하려고 할 것이다. 그런데, 이 Pod이라는 것이 동적으로 생성되고, 장애가 발생하면 자동으로 재기동되면서 그때마다 IP가 바뀌기 때문에, 로드밸런스에서 Pod 목록을 지정할 때 IP 주소를 이용하는 것이 어렵다. 따라서, IP를 대체하는 방법을 kubernetes는 제안하는데, 이것이 라벨과 라벨 실렉터이다. 그리..

※ 설치 버전 : 1.11.3 기준 웹 기반 kubernetes 사용자 인터페이스 제공. Dashboard를 사용하여 Kubernetes 클러스터에 컨테이너 화 된 응용 프로그램을 배포하고, 배포된 응용 프로그램의 문제를 해결하며, 수행하는 리소스와 함께 클러스터 자체를 관리할 수 ​​있다. Dashboard를 사용하여 클러스터에서 실행 중인 응용 프로그램의 상태를 쉽게 확인 가능하며, 개별 Kubernetes 자원 (예 : 배포, 작업, DaemonSets 등)을 만들거나 수정할 수 있다. 예를 들어 배포 마법사를 사용하여 배포를 확장하거나, 롤링 업데이트를 시작하거나, 포드를 다시 시작하거나, 새 응용 프로그램을 배포할 수 있다. 또한, Dashboard는 클러스터의 리소스 상태 및 발생한 오류에 대..

한마디로 정의하자면, 고성능에 초점을 맞춘 pub/sub 모델의 메시지 관리자라고 말하겠다. 메시지를 생성하는 곳(producer)과 소비하는 곳(consumer)를 분리하여, 메시지 자체를 관리하는 것에만 초점을 맞춤. producer와 consumer는 다대다의 복잡한 관계를 맺지 않고, 서로 Kafka와 1~다 대 1 관계를 맺으면 됨. - 중앙 집중형 메시지 관리 디스크 저장 방식 - 일반적은 메시 지큐는 consumer가 메시지를 읽어가면 큐에서 삭제됨. 하지만 kafka는 보관 주기 동안 메시지를 보관. 멀티 컨슈머가 가능한 이유. 그 외 메시지 손실 없는 다양한 작업이 가능 (consumer 수정 등) 기본 용어 정리 1. Broker : Kafka 가 설치되어 있는 서버/Node 2. To..

application을 위한 하나의 독립된 가상화 플랫폼. Container 안에 application을 넣고, 필요 라이브러리, 시스템 도구 등을 넣어 문을 걸어 잠그면, 이 application은 Container 안에서 독립적으로 실행 된다. 이것이 왜 좋으냐고 한다면, 이 컨테이너 속은 언제나 같음을 보장하며, 이 동일한 플랫폼을 판화 찍듯이 쉽게 생성할 수 있기 때문이다. 즉, Docker를 사용하면 시스템 환경에 구애받지 않고 애플리케이션을 신속하게 배포 및 확장할 수 있으며 코드가 문제없이 실행될 것임을 확신할 수 있다는 것이다. 이렇게 얘기하면, 대개는 기존의 서버를 VM으로 쪼개 쓰는 것과 무엇이 다른가를 비교하곤 한다. 일단, docker는 소프트웨어 플랫폼이다. VM을 구성하든 안하든..

※ CentOS 7 기준으로 작성됨. ※ 내부 베어메탈 서버에 쿠버네티스를 설치하는 가이드이며, 1.11.3 버전에 특화되었다. kubernetes.io 의 공식 가이드를 참조한 방식이며 100% 수동이다. 추후에는 분명 자동화된 설치방법이 나오겠지.. ※ 최소 요구 서버 수 - master를 single로 구성시에는 최소 master 1대, node 1대 총 2대. - master를 HA구성시에는 최소 master 3대, node 3대 총 6 대. (node가 3대 이하여도 설치도 되고 동작도 되나, 실제 서비스에는 그렇게 하지 말자) 1. Docker Install - kubernetes의 모든 host는 container 기반. docker는 가장 인기있고 보편적인 container. - verio..

보통 main메소드에서 시작해서 개발자의 의도대로 오브젝트가 생성되고 실행된다. 그런데 서블릿은 컨테이너가 권한을 가진다. 그렇다. 이미 제어 역전은 폭넓게 적용되고 있는 것이다. 템블릿 메소드 패턴도 슈퍼클래스로 템플릿 메소드를 통해 제어를 넘긴 것이다. 이것도 Ioc를 기반으로한 패턴이다. 팩토리 패턴도 객체생성에 대한 제어를 애플리케이션 코드에서 분리하는 IoC의 적용 패턴으로 볼 수 있다. > 팩토리 클래스를 하나의 Configuration Context 로 보면 이해됨 ※ 라이브러리 VS 프레임워크 - 라이브러리는 사용자가 능동적으로 애플리케이션의 흐름을 직접 제어하면서 사용하는 것 - 프레임워크는 사용자의 애플리케이션 코드를 프레임워크의 기반하에 흐름을 주도하는 것이다. 즉, 프레임워크는 분명..