본문 바로가기

service4

Kubernetes label 부분 정리 kubernetes 를 공부하면서, 가장 애매했던 부분이 label 이였습니다. Client ---> Pod 까지 어떤 label을 참조 하는지 정리된 문서를 찾아보다가.. 그냥 내가 보기 편하게 만들어 봤습니다. 간단하게 kubernetes 의 label 부분을 정리하니 아래와 같이 표현 되더군요.. ( 정말 간단하게 정리해 봅니다.) - 저는 rancher 2.x 기반으로 구축을 진행하고 있기 때문에. Ingress 설정은 다를수 있습니다. 해당 flow를 옆으로 펼쳐 보면 아래와 같이 좀더 label 기준으로 확인이 가능하겠네요.. 정리해 보면.. 1. pod : lables 설정. 2. Service & Deployment : label selector 설정. * Service 는 name 설정... 2019. 9. 17.
GSLB + Service Flow 3 GSLB + Service Flow 3 GLSB의 등록 정보 (or 관리 정보) 를 정리 합니다. GSLB는 크게 2가지로 관리되어 집니다. 첫째는 도메인 관리 이고, 둘째는 Host (server IP) 관리 입니다. 시간이 되면 차후에 좀더 세부적인 내용을 올려 보겠습니다. Host 관리 - 등록된 Server 정보 및 health check 정책, 분산정책 과 상태 정보를 관리 합니다. GSLB는 등록된 서버의 상태를 체크하여 enable/disable을 자동으로 처리하게 됩니다. 가령 web서비스면 80,443을 health check 정책으로 적용하면 될것입니다. 즉 장애구분은 서버의 80,443 포트 (TCP)의 open 여부로 판단합니다. ( HTTP도 가능합니다. ) 즉 CDN 으로 본다면.. 2019. 3. 5.
GSLB + Service Flow 정리 2 GSLB + Service Flow 정리 2 GLSB의 기능에 대해 정리 합니다. 가중치 (Weighted or Ratio ) - 가령, 특정한 서버 또는 Node로 DNS request 를 더 많이 보낼수도 있습니다. 예를 들면.. 특정 IDC의 트래픽을 종량제로 계약을 했다면 .. 즉 1달간 3G 정도를 무료로 사용할수 있다면 그쪽으로 트래픽을 좀더 흘려 보내서 비용을 절약할수도 있습니다. 아니면, IDC별 회선 단가비율에 따라, 조절을 할수도 있겠습니다 . 인프라를 관리하는 사람이라면 회선비용을 무시할수 없을 것입니다. 또는 WEB 서버의 성능에 따라, 비율조정을 해 줄수도 있습니다. (가중치를 높히면 더 많은 request 를 받고, 트래픽은 상승하겠죠..) 한가지 주의할 점은.. GSLB는 L4.. 2019. 3. 5.
GSLB + Service Flow 정리 - 1부 GSLB + Service Flow 정리 * 기능에 대해서 간단하게 정리합니다. 시간을 두고 좀더 세부적인 내용도 같이 올리겠습니다. DNS 와 GSLB의 가장 큰 차이점은 서버의 장애 발생시 failover 된다는 것입니다. DNS일 경우, 아래와 같이 등록된 A record 가 3개가 있다고 할때, 서버 장애에 대한 failover 정책이 없다는 것입니다. DNS Flow 반면.. GSLB의 경우는 내부의 헬크체크 정책에 의해 서버의 장애시 제외 처리가 가능합니다. GSLB Flow 보통, CDN업체의 경우 아래와 같이 고객도메인과 CNAME통해 연결을 하게 됩니다. CDN 업체는 GSLB의 GeoIP 를 통해, 지리적 분산처리를 합니다. (미국 사용자는 미국의 edge 로.. ) CNAME Flow 2019. 3. 5.