본문 바로가기

분류 전체보기

 (345)
볼륨: 컨테이너에 디스크 스토리지 연결 쿠버네티스의 볼륨은 Pod의 컴포넌트이므로 컨테이너와 마찬가지로 Pod의 스펙에 정의 볼륨은 독립적인 쿠버네티스 오브젝트가 아니며 스스로 생성하거나 삭제할 수 없다. ㅁ 사용 가능한 볼륨 유형 - emptyDir: 일시적인 데이터를 저장하는 데 사용되는 비어있는 다순한 디렉터리 - hostPath: 워커노드의 파일 시스템에서 Pod로 디렉터리를 마운트하는 데 사용 - gitRepo: Git 스토리지의 내용을 체크아웃해 초기화된 볼륨 - nfs: Pod에 마운트된 NFS 공유 - gcePersistentDisk(구글 컴퓨트 엔진 영구 디스크), awsElastic-BlockStore(AWS EBS), azureDisk(마이크로소프트 애저 디스크 볼륨): 클라우드 제공자에 따라 전용 스토리지를 마운트하는데 ..
외부 서비스에서 외부 클라이언트로...(Nodeport, Loadbalancer, Ingress) [서비스가 외부에서 액세스 가능하게 하는 방법] ㅇ. NodePort 서비스 타입으로 설정하기 - NodePort 서비스의 각 클러스터 노드는 노드 자체 이름을 통해 port를 열고 port에서 발생한 트래픽을 서비스로 Redirect함. ㅇ. LoadBalancer 서비스 타입으로 설정 하기 - Kubenetes가 실행 중인 클라우드 인프라스트럭처에 provision된 지정된 LoadBalancer를 통해 서비스 액세스 가능 ㅇ. Ingrea Resource 생성하기 - HTTP fpqpf(네트워크 7계층) 수준에서 동작하기 때문에 4계층 서비스보다 좀 더 기능을 제공 1. NodePort 서비스 ㅁ NodePort 서비스 생성 apiVersion: v1 kind: Service metadata: na..
외부 서비스에 연결 (Endpoint) ㅁ 서비스 Endpoint Service는 Pod를 직접 link하지 않는다. 대신 Endpoint라 불리는 리소스가 Pod와 Service 사이에 위치 한다. $ kubectl describe svc kubia 와 같은 describe 명으로 서비스 확인 가능 get endpoints로 endpoint 정보 확인 가능 $ kubectl get endpoints kubia ㅁ 수동으로 Endpoint 설정 - Selector 없이 Service 생성 apiVersion: v1 kind: Service metadata: name: external-service spec: ports: - ports: 80 80으로 들어오는 연결을 처리하는 external-service를 정의 - Selector없이 Serv..
CloudHub 패턴 - VPN 지점 설치 ㅁ 풀어야 할 문제 여러 지점 간의 VPN 접속을 풀 메쉬 토폴로지(Full Mesh Topology)형으로 구축하면, 지점이 늘어남에 따라 각 지점 VPN 라우터 설정도 복잡해지고 유지보수 비용도 늘어난다. 이 문제를 해결하기 위해 스타 토폴로지(Star Topology)형으로 VPN을 구축하면, 각 지점의 VPN 라우터는 VPN 허브에 접속만 하면 된다. 그러나 VPN 허브에 장애가 발생하면 모든 VPN 접속에 영향을 주기 때문에 VPN 허브의 가용성이 가장 중요하다. ㅁ 해결/패턴 기존 VPN 허브는 가용성을 높이기 위해 VPN에 이용하는 통신 기기를 이중화하는 등 높은 초기 비용이 들었다. 또한 VPN 접속 이용량에 상관없이 장비 유지에 대한 고정 비용이 발생하여 비용 효율이 좋지 않았다. 클라우..
Web Proxy 패턴 - 고가의 Web Application Firewall 의 효율적 활용 ㅁ 풀어야 할 문제 전자상거래 사이트 등 중요한 개인정보(신용카드 정보 등)를 사용하는 웹 사이트는 보안 강화를 위해서 WAF(Web Application Firewall)를 도입하는 경우가 있다. 그러나 클라우드 에서의 시스템은 작은 규모로 구축된 시스템이 많고, 대부분의 경우 WAF 도입은 고려하지 않는다. 또한, 스케일 아웃/인에 따른 서버의 추가 및 삭제를 고려한 시스템이 많은데, 그런 때는 필요한 라이선스 수를 알 수 없기 때문에 WAF 도입은 어렵다. ㅁ 해결/패턴 기존에는 서버 대수를 결정하고 준비하기 때문에 도입하는 WAF 대수도 정해져 있어 특별히 문제는 없었다. 그러나 시간 단위로 서버의 추가/삭제가 이루어질 수 있는 클라우드 환경에서는 그 서버에 WAF를 도입하는 것은 비현실적이고, ..
Multi Load Balancer 패턴 - 복수 로드 밸런서 설치 ㅁ 풀어야 할 문제 웹 애플리케이션을 멀티 디바이스에서 사용해야 하는 경우 PC나 휴대폰, 스마트 폰에서 액세스해야 한다. 그 때 액세스 디바이스별로 SSL이나 세션 분배 등의 설정을 해야 하는데, EC2 인스턴스 자체에 그런 설정을 하게 되면 서버가 늘어나거나 설정 변경 시의 작업이 정말 번거로워진다. ㅁ 해결/패턴 웹 애플리케이션을 호스팅하고 있는 가상 서버 그룹에 대해 설정이 다른 여러 대의 가상 로드 밸런서를 할당하여 문제를 해결 할 수 있다. 결국, 서버에 설정을 하지 않고 각 디바이스에서의 액세스를 가상 로드 밸런서를 경유하도록 변경할 수 있게 된다. 예를 들어, 세션이나 상태 확인, HTTPS 등의 설정이 그것이다. ㅁ 구현 하나의 Ec2에 여러 대의 ELB(가상 로드 밸런서)를 할당한다. ..
Operation Firewall 패턴 - 기능별 액세스 제한 ㅁ 풀어야 할 문제 대규모 시스템이 되면 개발 보수 조직이 많이 존재한다. 예를 들어, 시스템 개발을 하는 회사, 로그 분석이나 운용 감시를 하는 회사 등으로 나뉘는 경우가 이에 속한다. 방화벽 룰을 기능별 그룹으로 정의한 경우, 액세스 대상이 변경되거나 액세스 자체를 제한하려고 할 때는 그때 그때 기능별로 그룹화된 룰을 변경해야 한다. 설정에 시간도 많이 걸리고 각각의 조직이 어느 서버에 액세스 할 수 있는지를 일원적으로 관리할 수 없다. ㅁ 해결/패턴 기존 장비는 전용 장비를 이용하고 룰도 기능별로 정리하여 적용(관리)하는 경우가 많았다. 클라우드에서는 방화벽은 가상화 되어 있어 보다 유연하게 설정할 수 있다. 룰을 그룹화하고 그룹 단위로 설정하거나 서버에 적용할 수 있다. 이 그룹이라는 단위를 조직..
Functional Firewall 패턴 - 단계적 액세스 제한 ㅁ 풀어야 할 문제 방화벽을 이용한 계층적 액세스 제한은 기존 시스템에서도 통상 해왔던 보안 대책이다. 그러나 액세스 제한 룰이 많아지면 방화벽의 설정도 많아져 복잡해지고 거기에 따른 운영 비용도 높아진다. 또한 방화벽 룰의 그룹화가 불가능한 경우 유지보수도 복잡해지고 실수할 가능성도 높아진다. ㅁ 해결/패턴 기존 방화벽은 전용 장비를 사용해 그룹화하지 않고 룰을 관리하는 경우가 많았다. 그룹화가 가능하다고 해도 서버 단위로 쉽게 적용하기는 어려웠다. 클라우드에서는 방화벽에 대해서도 가상화 되어 있어 보다 유연하게 설정할 수 있게 되어 있다. 그리고 룰을 그룹화하여 그룹 단위의 설정이나 각 서버로의 적용이 가능한 것도 있다. 이 그룹 단위를 기능별(웹이 DB 등)로 하게 되면 기능에 관한 설정을 그룹 내..

티스토리툴바