Container
우리는 어떤 서비스를 만들기 위해서 그 서비스 구축을 위한 환경을 조성해줘야한다. 그 환경에서는 OS, Software같은 것을 필요로 하게 되는데, 하나의 시스템안에서 두 개 이상의 software를 동시에 실행하고 싶을 때가 있다. 하지만 일반적인 시스템의 경우에는 같은 시스템 내에서 두 개 이상의 software를 동시에 실행할 수는 없다.
이런 이유때문에 가상머신(Virtual Machine)의 개념이 등장했다. 가상머신은 하나의 시스템위에서 그 시스템의 리소스로 여러 개의 환경을 구축하고 동시에 실행할 수 있도록 도와준다. 하지만 동시에 운용하고 싶은 환경이 매우 많은 기업이나 서비스에서는 일일이 이 가상머신의 환경을 세팅해줘야 한다. 그렇다면 서비스를 구축하는데에 들어가는 시간적 비용, 금전적 비용이 많이 증가하게 될 것이다.
Container 기술은 가상머신의 단점들을 보완하여 간편하게 환경을 구축할 수 있게 도와준다. Container는 Image라는 컨테이너 실행에 필요한 파일과 설정값을 이용하여 Container 실행시에 환경을 자동적으로 세팅해준다. 즉, Container는 실행의 독립성을 확보해주는 운영체계 수준의 격리 기술인데 이런 환경에 필요한 파일들을 패키징한 Image를 통해 구현한다.
위 그림에서 VM은 Host OS 위의 Hypervisor를 사용해서 각 GuestOS 위에 환경을 구축한다. 하지만 오른쪽의 Container는Hypervisor를 사용하지 않고 Host OS위에 Container Runtime이 각각의 Container를 생성하여 환경을 구축한다. 이때 Container는 Image를 사용해 간편하게 Container를 생성할 수 있다.
Hypervisor란, Host OS가 가지는 인프라 리소스들을 VM들에게 적절히 나누어주는, 배분하는 역할을 하는 기능이다.
가상 머신(독립적인 플랫폼)을 만들때마다 매번 Hypervisor가 리소스를 배분해줘야 하기 때문에 비효율적이며 확장성이 좋지 않다.
Monolithic vs Micro Service
위에서 가상머신 또는 Container 단위로 서비스를 독립적으로 구축하는 방식에 대해 설명해보았다. 그렇다면 왜 독립적으로 구축하는 것일까? 그냥 단일환경에서 여러 서비스를 구현하면 안되는가?
단일 환경에서 여러 서비스를 구현하는 방식이 Monolithic Service이다. Monolithic 방식은 하나의 고용량 고성능 단일 서버에 여러 서비스를 구동시키는 것이다. 이 방법은 하나의 단일 환경에서 서비스들을 구동시키기 때문에 복잡하지 않고 간단하게 서버를 구축할 수 있다. 또 하나의 서버에서 운용하기 때문에 편리한 부분이 있으며, End-to-End 테스트를 할 때 용이하다.
다만 Monolithic 방식은 한 프로젝트의 크기가 너무 커져서 어플리케이션의 구동시간이 늘어나고 빌드, 배포 시간도 늘어난다. 많은 양의 코드가 몰려있고 기능별로 다른 언어가 사용될 수 있으며, 모든 서비스에 알맞는 프레임워크를 찾기도 어렵다. 가장 치명적인 단점은 하나의 오류가 모든 서비스에 영향을 미칠 수 있다는 것이다.
Micro 방식은 각각의 서비스들을 각기 다른 서버에 위치시켜 운용하는 방식이다. 원하는 서비스만을 중단, 시작, 종료할 수 있고 빠른 배포와 빌드가 가능하다. 각기 다른 서버에 위치해있기 때문에 일부에 오류가 발생하더라도 그 부분의 서비스만을 점검할 수 있다.
예로 네이버 메인 페이지에 들어가면 상단에 여러가지 기능들이 존재한다. 뉴스부터 금융, 날씨 등등 여러가지 편의 기능들이 있는데 네이버는 이것들을 Micro Service 방식으로 운용한다. 때문에 네이버 뉴스 서비스가 문제가 발생하더라도 다른 서비스는 그대로 가동하면서 점검이 가능하고 개발도 각기 다른 서비스마다 다르게 진행할 수 있다.
Docker
도커는 위에서 설명한 Container를 Image단위로 불러오거나 배포하고 Container라는 독립적인 환경을 구축할 수 있도록 도와주는 도구이다.
도커는 도커허브라는 공개 저장소를 이용해서 컨테이너 자료들을 관리한다. 때문에 사용자들은 편리하게 도커허브에서 Image를 다운받고 Container를 생성할 수 있으며, 자신이 만든 Image들도 배포할 수 있다.
Dockerfile
도커에서는 도커파일을 이용하여 Image를 생성한다. 즉, 도커파일은 Image생성을 위한 레시피 파일인 셈이다.
Docker Image
도커의 이미지는 서비스 운영에 필요한 프로그램, 소스코드, 라이브러리등을 묶고 있는 형태로 Dockerfile에 의해 생성(Build)될 수 있다. 이 도커 이미지를 사용해서 여러 Container를 만들고 실행할 수 있다.
도커 이미지는 사용자가 직접 Dockerfile로 생성해줄 수도 있지만 도커허브에서 다운받아(pull) 사용할 수도 있다.
쿠버네티스 (Kubernetes)
컨테이너 오케스트레이션
오케스트라에서 지휘하는 지휘자의 역할을 하는 오케스트레이터, 다수의 Container를 관리하는 컨테이너 오케스트레이션의 역할과 비슷하다. 대표적인 도구 중 하나가 쿠버네티스이다.
컨테이너 오케스트레이션은 다수의 컨테이너가 자동적으로 scaling되고 대규모 배포를 도와주고, 관리할 수 있도록 도와준다. 마치 AWS에서 여러 가상머신들을 대상으로 간편하게 관리할 수 있도록 도와주는 서비스와 비슷하다고 볼 수 있다.
컨테이너 오케스트레이션의 큰 역할은 다음과 같다.
- 배포 관리 : 어떤 컨테이너를 어느 호스트에 배치하여 구동시킬 것인가? 각 호스트가 가진 한정된 리소스에 맞춰 어떻게 최적의 스케줄링을 구현할 것인가? 어떻게 하면 이러한 배포 상태를 최소한의 노력으로 유지 관리할 수 있을 것인가?
- 제어 및 모니터링 : 구동 중인 각 컨테이너들의 상태를 어떻게 추적하고 관리할 것인가?
- 스케일링 : 수시로 변화하는 운영 상황과 사용량 규모에 어떻게 대응할 것인가?
- 네트워킹 : 이렇게 운영되는 인스턴스 및 컨테이너들을 어떻게 상호 연결할 것인가?
Kubernetes의 구조
쿠버네티스는 cluster라는 노드 머신을 사용해 컨테이너들을 관리한다.
cluster의 구조는 아래와 같다.
먼저 cluster는 크게 Master node인 Control Plane, 일반 노드인 Worker node로 구분할 수 있다. Master Node인 Control Plane은 클러스터에서 전반적인 결정을 수행하고 명령을 내릴 수 있도록 설계된 node이다.
Master Node (Control Plane)
클러스터의 마스터 노드에는 4가지의 구성요소가 있다.
- API Server
- Scheduler
- Controller Manager
- etcd
먼저, API Server는 모든 다른 구성요소가 통신할 수 있도록 하는 api 기반의 통신 매개체라고 볼 수 있다. 사용자가 클러스터에게 pod(container를 담는 곳)를 생성하라고 지시한다면 Control Plane 내부에서 여러 과정을 거친뒤 API Server를 통해 worker node에게 pod를 생성하는 명령을 내린다.
etcd는 클러스터 내부의 모든 구성요소에 대한 정보를 담는 공간이다. etcd를 통해 클러스터의 고가용성을 달성할 수 있으며, etcd의 정보를 참조해 scheduler가 어느 노드에 pod를 생성할 지 결정하기도 한다. 또 worker 노드의 상태를 전송받아 저장하는 곳이기도 하다.
Scheduler는 새롭게 생성될 pod가 어떤 노드에 위치할 지 결정한다. 정확히는 스케쥴러가 어느 노드에 pod를 생성할지 정하고 노드의 spec을 변경한 뒤 이 정보를 API Server에 전송한다. 그러면 API Server는 그 노드의 Spec이 변경되었기 때문에 자동적으로 pod의 개수를 변경하라는 명령을 해당 worker node에 보내게 된다.
Controller Manager는 API Server를 통해 Worker node의 pod 리소스의 변경을 감시하고 변경하는 작업을 한다. 클라이언트가 초기에 설정한 Spec으로 계속해서 조정하며 현재 상태를 Status에 저장한다.
Worker Node
Master Node의 API Server로부터 pod 생성 명령을 받으면 Worker Node는 내부 기능들이 작동하면서 pod를 생성한다. Worker Node가 실제 어플리케이션이 구동되는 부분이다.
Worker Node의 구성은 다음과 같다.
- kubelet
- Container Runtime
- kube-proxy
먼저 kubelet은 작업반장님같은 느낌으로 master로부터 pod 생성 지시를 받아 Image를 참고하여 Container runtime과 함께 pod를 생성한다. 또 kubelet은 container를 지속적으로 모니터링하고 그에 대한 리포트를 API Server에 전송하기도 한다.
Container Runtime은 컨테이너를 실제 실행시키는 역할을 한다. 또 컨테이너 이미지도 같이 관리한다. Container Runtime으로 사용할 수 있는 Runtime은 도커, CRI-O, containerd, rkt, rktlet 등이 있는데 docker는 지원이 종료되었고 CRI-O나 containerd를 주로 사용한다.
마지막으로 kube-proxy는 외부에서 pod로 접근하려고 할때 port를 열어주는 역할을 한다.
Addons
Addons는 쿠버네티스에서 추가적으로 설치하여 기능을 확장할 수 있도록 하는 도구이다. 쿠버네티스에서 Addons 도구로 추가 설치할 수 있는 것들은 다음과 같다.
- DNS : DNS 레코드를 제공해주는 DNS 서버 (대부분의 컨테이너들이 사용)
- Dashboard : 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI
- Monitoring : 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공
- Logging : 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장
- Etc
쿠버네티스 배포와 여러 기능
쿠버네티스의 배포 유형에는 4가지 방식이 있다.
유형은 아래와 같다.
1. All-in-One Single-Node Installation
위에서 쿠버네티스의 클러스터 구조에 대해서 설명할 때, Master Node와 Worker Node가 구분되어 있는 것처럼 설명했었다. 사실 그 클러스터의 구조는 여러가지로 배포될 수 있는데 위 처럼 하나의 노드에 master와 worker가 모두 들어있는 경우이다.
한 노드안에 모든 기능이 들어있는 All-in-One Single-Node Installation의 경우에는 Node에 문제가 생기거나 Master에 문제가 생기면 worker 내 모든 pod, container들이 연달아 문제가 발생하고 사용하지 못하게 된다. 또한 etcd가 node의 master 안에 있기 때문에 복구하지도 못한다.
2. Single-Node etcd, Single-Master and Multi-Worker Installation
다음 배포 유형은 위와 같은 구조를 가진다. 각 기능들이 하나의 노드안에 들어있는 경우이다. 이전 유형처럼 하나의 노드가 문제가 생겼을 때 연달아 다른 기능도 문제가 생기지는 않는다. 다만 Master Node는 하나이기 때문에 Master Node에 문제가 발생했을 때 문제점이 발생할 수 있다. (etcd도 Master안에 같이 있기 때문에 Master Node에 문제 발생 시 복구가 불가능할 수도 있다.)
3. Single-Node etcd, Multi-Master and Multi-Worker Installation
다음 배포 유형은 위와 같은 구조를 가진다. Master Node도 여러개 Worker Node도 여러개를 가진다. 이때는 Master, Worker Node 각각 하나의 노드에서 문제가 생기더라도 대체할 수 있는 node가 있기 때문에 가용성이 높다.
하지만 아직 etcd는 하나이기 때문에 etcd가 들어있는 Master Node에 문제가 생기면 복구할 수 없다는 문제점이 남아있다.
4. Multi-Node etcd, Multi-Master and Multi-Worker Installation
마지막 배포 유형은 위와 같은 구조를 가진다. etcd도 모두 다른 Master Node에 있고 Master, Worker Node가 여러 개 있어 가용성이 가장 좋은 방식이다. 한 Master Node에 이상이 생기더라도 다른 Master Node가 있어 운용에 문제가 발생할 가능성이 낮으며 etcd가 각자 존재하기 때문에 어떤 Master Node에 문제가 생기더라도 복구할 수 있다.
Kubernetes 배포 순서
쿠버네티스 배포 순서는 다음과 같다.
- Container Runtime 설치
- Kubernetes 설치
- Master와 Worker 연동
Master와 Worker는 AWS의 cloud9 서비스를 사용해서 생성해주며 연결 또한 가능하다.
Kubernetes 컨테이너 배포, 통신, 볼륨 관리
Object
쿠버네티스에서 Object는 쿠버네티스에서의 가장 기본적인 구성단위이다.
가장 기본적인 Object
- Pod
- Service
- Volume
- Namespace
위의 각 object들은 Spec과 Status가 존재하는데 Spec은 Object를 생성할 때 설정하는 정의된 상태, 목표상태를 의미하고 Status는 현재 상태를 의미한다.
Controller
쿠버네티스의 Controller는 Master Node에서 Controller Manager에 포함되어 있는 기능들이다. Controller의 대표적인 유형으로는 Deployment, Replicaset, Daemonset 등이 있다.
Controller는 클러스터의 상태를 항시 모니터링하면서 Spec을 참조하여 Status를 Spec에 가깝게 유지하려고 하는 특징을 가진다.
Controller는 위와 같이 해당 Object가 가지는 Spec(Desired State)와 현재 상태 state가 다르다면 이를 같아지도록 조치하는 역할을 한다.
Auto Healing
쿠버네티스에는 Pod나 Node가 손상되었거나 정상작동을 하지 못할때 이를 자동적으로 정상상태로 돌리는 기능이 있다. 그것이 Auto Healing이다. 먼저 Controller에서는 계속해서 각 pod들을 모니터링하고 있기 때문에 기능에 문제가 발생하면 즉시 인지하고 처리할 수 있다.
Auto Scaling
Auto Healing과 아주 비슷한 기능이다. Auto Scaling은 AWS에서 지원하는 ASG와 아주 비슷하다. pod에 접근하는 트래픽이 많아져 리소스에 부하가 걸리면 새로운 pod들을 추가적으로 생성한다. 또 트래픽이 적어져서 리소스 부하가 적어지면 자동적으로 추가되었던 pod들이 자동적으로 제거된다.
Update & Rollback
쿠버네티스는 deployment object 기능을 사용해서 각 pod들의 버전관리도 가능하다. 버전 갱신 방식은 이후에 다룰거지만 기본적으로 각 pod들이 가지는 버전에 대해서 update가 가능하고 다시 이전 버전으로 되돌아가는 rollback도 가능하다.
쿠버네티스의 object들은 YAML 파일을 시작으로 생성된다. YAML 파일에는 연결할 API 버전, 리소스 유형, metadata, spec 등 여러가지 정보가 담겨 있고 이를 실행했을 때 해당 object가 생성된다.
또 쿠버네티스에 명령을 내릴 때는 kubectl라는 쿠버네티스의 CLI 명령어를 사용한다. kubectl을 사용해서 오브젝트와 컨트롤러를 생성하고 수정, 삭제할 수 있다.
Pod
Pod는 쿠버네티스에서 가장 작은 object로 하나 이상의 container를 가지는 그룹이다.
Pod 자체는 Auto Healing, Auto Scaling 기능이 없고 Controller가 해줘야한다.
명령어는 교안 참고
Namespace
Namespace는 여러개의 pod를 가지고 있는 공간으로 하나의 클러스터안에 여러개의 Namespace가 존재할 수 있다. 이 Namespace는 한 회사에서 진행하는 프로젝트의 경우에 각 팀별로 가지고 있을 수도 있고 서비스 종류별로 구분되어 존재할 수도 있다.
Controller
Replicaset
Replicaset은 쿠버네티스의 controller 중 하나로 replicas 라는 개수를 yaml파일에 명시해두면 Auto Healing에 의해 pod에 문제가 발생하면 그 개수를 유지하려고 새로운 pod를 생성한다.
파드 개수에 대한 가용성을 보증 하며 지정한 파드 개수만큼 항상 실행될 수 있도록 관리한다.
Replicaset은 pod를 생성하는 템플릿 명세가 yaml에 같이 존재해서 Replicaset이 pod를 생성할 때 템플릿을 참조한다.
Deployment
Deployment는 Replicaset들을 관리하며 더욱 세밀하게 어플레이션 배포를 더욱 상세하게 관리한다. Deployment에는 버전관리 기능이 있어서 초기 배포 이후 update, rollback이 가능하다.
deployment는 위의 구조처럼 replicaset을 관리하고 replicaset은 pod를 관리하는 계층적 구조를 가진다.
Deployment의 Update
Deployment가 버전을 업데이트하게 되면 pod들도 모두 업데이트를 해야하는데 이를 replicaset을 사용해서 한번에 진행할 수 있다. 이 때 버전 업데이트를 하게 되면 이전 버전의 replicaset을 지우는 것이 아니라 replicaset의 replicas를 0으로 만들어 이전 버전의 .pod들은 모두 사라지게 된다.
update 이후에 이전 버전으로 rollback하고 싶다면 현재 버전의 replicaset replicas를 0으로 만들고 이전 버전의 replicas를 변경해주면 된다!
Update시 방식
Deployment가 update할 때 pod들을 한번에 갈아버리는 recreate방식과 downtime이 없게 하는 rolling update방식이 있다.
Recreate방식은 버전이 업데이트될 때 기존의 pod들을 모두 제거한 뒤 새로운 pod들을 생성한다. recreate 방식은 간단하지만 downtime이 존재해서 업데이트를 할 때는 사용자가 이용할 수 없는 문제가 발생한다.
Rolling update방식은 상위 버전의 pod를 먼저 하나 생성하고 이전 버전의 pod를 하나씩 제거하면서 생성하는 것을 반복한다.
Service
쿠버네티스에 service는 pod에 접근하기 위해 필요한 object이다.
service는 외부에서 pod에 접근할 수 있도록 도와주는데 고정적인 주소를 제공하고 쿠버네티스 내부에서 내부로도 통신이 가능하도록 하는 네트워크 서비스이다. (pod는 매번 새로운 IP 주소를 할당받아 생성되기 때문)
Service에 의해 네트워크 연결이 가능하도록 도와주는 역할을 하는 것이 세가지 있는데 다음과 같다.
- Label : pod와 같은 object에 그 object의 정보를 나타내는 key와 value
- Selector : 서비스 object에 명시되어있는데, selector의 값과 동일한 Label만을 찾아 해당 object만 관리할 수 있도록 함
- Annotation : Label - Selector관계처럼 Object를 찾는데 사용되지는 않지만 참조할만한 내용들이 담겨있음
이 세가지 역할은 대부분의 서비스 유형에서 사용된다.
서비스 유형
- ClusterIP (기본 형태)
- NodePort
- LoadBalancer
- ExternalName
먼저 Cluster IP는 클러스터 내부에서 통신이 가능하도록 하는 기능이다. 내부에서 port를 뚫어주는 역할을 하기 때문에 외부 트래픽을 pod로 곧바로 전송할 수는 없다. 외부에서 트래픽이 들어오면 Cluster IP Service가 먼저 트래픽을 받고 이후 로드 밸런싱 기법으로 pod들에게 트래픽을 전송한다. 외부에서 직접 pod에 트래픽을 전송하고 싶을 때는 Nodeport나 로드밸런서를 이용해야한다. (ClusterIP는 기본 Service이다, default)
NodePort는 Cluster IP가 내부에서만 접근할 수 있다는 단점을 보완하여 외부에서도 접근할 수 있도록 port를 뚫는 방법이다. 외부에서 Nodeport에 접근하면 Nodeport는 ClusterIP와 연결되어 있기 때문(Nodeport에는 Cluster IP가 기본적으로 존재)에 Cluster IP로 이동하고 Cluster IP 서비스에서 pod들에게 전달하는 순서로 트래픽이 이동한다.
위의 yaml파일처럼 Nodeport 서비스 객체의 spec에는 port가 명시되어 있다. 외부에서 nodePort로 진입하면 NodePort 서비스는 포트 포워딩처럼 Cluster IP Service로 이동(nodePort → port)시켜주고 Cluster IP는 Pod로 이동할 수 있도록 한다. (port → targetPort)
NodePort는 30000~32767까지의 포트중에서 랜덤으로 결정되고 원한다면 지정할 수도 있다. NodePort를 통해서 클러스터 내부 어떤 node(pod)에든 접근할 수 있기 때문에 임의의 노드로 접근한 뒤 원하는 지정node에 접근할 수 있다.
위 예시를 가지고 순서대로 트래픽을 전달해보자. (nodePort 30000, port 80, target port 8080)
- 외부의 트래픽이 클러스터 외부의 nodeport에게 접근을 요청한다. (30000 port로 요청)
- nodeport는 80 port로 외부 트래픽을 서비스(cluster ip)에 전달한다.
- 서비스(cluster ip)는 target port인 8080을 통해 각 pod(container)에 트래픽을 전달한다.
Nodeport는 어떤 노드로 접근해도 지정된 노드로 트래픽을 이동시킬 수 있지만 그 노드가 살아있는 노드인지는 판단할 수 없다. 즉, auto scaling, auto healing과 같은 기법에 의해 기존의 노드가 죽는다면 그 노드에 접근하는 nodeport는 잘못된 접근이 발생할 수 있는 것이다. (죽은 노드에 접근)
이 문제를 보완한 것이 Load Balancer Service이다.
로드 밸런서는 외부에서 살아있는 노드들에게 트래픽을 분산하여 전달하는 기능이다. 로드밸런서에서 외부 트래픽을 받으면 Nodeport에 전달하고 Nodeport는 service에 전달 service는 node들에게 전달하게 된다.
Reference
컨테이너 및 도커 개념정리
소프트웨어는 OS와 라이브러리에 의존성을 뛴다. 그러므로 하나의 컴퓨터에서 성격이 다른(OS,라이브러리 버전이 다른) 소프트웨어를 한번에 실행할 때 어려움을 가질 수 있고 관련된 구성을 관
velog.io
https://tecoble.techcourse.co.kr/post/2021-08-14-docker/
docker 이해하기
…
tecoble.techcourse.co.kr
(마이크로 서비스 vs 모놀리식 아키텍처) MicroService vs Monolithic Architecture 간단 소개 및 주관적 의견
모놀리식 아키텍처 (Monolithic Architecture) 장점 1. 어떤 기능(서비스)이든지 개발되어있는 환경이 같아서 복잡하지않다. 2. 쉽게 고가용성 서버 환경을 만들 수 있다. ( 같은 어플리케이션으로 하나
lion-king.tistory.com
[Infra] 쿠버네티스(kubernetes)(1) 쿠버네티스 구조(Kubernetes architecture)
쿠버네티스(kubernetes)(1) 쿠버네티스 구조(Kubernetes architecture)
losskatsu.github.io
https://sphong0417.tistory.com/53
[Kubernetes 내부 구조 이해하기] 1. 쿠버네티스 클러스터 구성 요소
그동안 쿠버네티스를 사용하면서 헷갈렸던 부분이나 사용은 했지만 원리를 알지 못했던 부분들에 대해 정리해보고자 글을 작성하려고 합니다. 이 글은 Kubernetes In Action을 읽고 참고하여 작성하
sphong0417.tistory.com
https://kubernetes.io/ko/docs/concepts/overview/components/
쿠버네티스 컴포넌트
쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인 컴포넌트로 구성된다.
kubernetes.io
쿠버네티스 애플리케이션 배포법
기본 오브젝트 파드 쿠버네티스에서 실행되는 최소 단위, 즉 웹 서비스를 구동하는데 필요한 최소 단위. 독립적인 공간과 사용 가능한 IP 소유. 디플로이먼트, 레플리카셋, 잡, 크론잡, 데몬셋,
velog.io
쿠버네티스(Kubernetes) 입문하기
쿠버네티스 안내서 따라하기 전에 한번 보고 하면 좋습니다!
blog.kubwa.co.kr
https://seongjin.me/kubernetes-service-types/
쿠버네티스에서 반드시 알아야 할 서비스(Service) 유형
파드는 특성상 생성될 때마다 내부 IP 주소가 계속 변화하게 된다. 쿠버네티스의 서비스(Service)는 이러한 파드에 탑재된 애플리케이션이 외부와 상호 통신이 가능하도록 만들어준다. 이번 글에
seongjin.me
https://yoonchang.tistory.com/49
[Kubernetes] 6. 쿠버네티스 Service란? (NodePort, nginx 실습)
[주의] 개인 공부를 위해 쓴 글이기 때문에 주관적인 내용은 물론, 쓰여진 정보가 틀린 것일 수도 있습니다! 피드백 부탁드립니다. (- -)(_ _) 꾸벅 [ Service ] 위 그림을 보면, 10.10.10.2의 내부 아이피
yoonchang.tistory.com
쿠버네티스 - 서비스(ClusterIP, NodePort, LoadBalancer)와 인그레스
오늘은 쿠버네티스의 서비스에 대해서 정리해보겠다. 입사 초반에 도커파일의 빌드 시간 단축 태스크를 진행하였는데, 도커파일 빌드를 로컬 컴퓨터에서 이리 저리 시도하기에는 너무 느려서
velog.io
https://real-dongsoo7.tistory.com/135
[Kubernetes] #5 NodePort, port, targetPort (feat.쉬어가기)
틈틈이 쿠버네티스 관련 서적들을 읽어가며 학습을 하고 있는데, 아무래도 단순히 읽고 예제를 따라가는 속도보다 블로그에 포스팅을 위해 글을 작성하고 정리하는 시간이 오래 걸리다 보니 포
real-dongsoo7.tistory.com
https://kubernetes.io/ko/docs/concepts/services-networking/_print/
서비스, 로드밸런싱, 네트워킹
쿠버네티스의 네트워킹에 대한 개념과 리소스에 대해 설명한다.
kubernetes.io
'네트워크 및 클라우드' 카테고리의 다른 글
| TCP/IP로 배우는 네트워크 1 (0) | 2023.01.19 |
|---|---|
| [가상화 클라우드] AWS (EC2, S3, EBS) (0) | 2022.11.03 |
| [WAS 기초]3 Tier 구현 실습 (포트 포워딩, NAT Network, etc..) (0) | 2022.11.02 |
| [리눅스와 웹서버 기초] 우분투, WAS (Web Application Server) (0) | 2022.11.01 |