Access to API Server
- 쿠버네티스 api 를 사용해서 클러스터에 접근 가능한 서버를 구성하는 항목으로 추정됨
- api 서버에 어플리케이션으로도 접근이 가능하다 (go, python, dotnet, js 지원 되고있는것으로 확인)
- 요즘 클라우드 gui 가 잘되어있어서 접근할일이 없을것같고 실제 서비스에서도 직접적으로 접근하는 일이 없을것같아서, 생성 서버는 가장 낮은 스펙 그리고 외부 접근은 제한 두는것이 좋을것같다.
Q. 열어두면 api 로도 접근이 가능하니 보안상 과연 좋을까? 좋지않은것으로 확인
+ 참고 링크: kubernetes.io/ko/docs/tasks/administer-cluster/access-cluster-api/
Service Discovery
- 쿠버 auto-scaling 시 자동으로 트래픽을 분산 시키도록 해주는 항목
- 세가지 방식을 제공한다. Disable / PrivateZone / CoreDNS
* Disable: 활성화 하지 않겠다라는 의미로 auto-scaling 시 직접 트래픽을 분산 시켜줄때 사용할것같다.
* PrivateZone: 알리 클라우드 VPC 기반으로 private DNS 를 제공해준다고한다. privateZone 을 사용하면 지정된 VPC에 있는 ip 주소(1개 이상)를 private 도메인으로 사용이 가능한것으로 이해함.
* CoreDNS: 민첩하고 확장가능한 DNS 서비스이고, 쿠버 표준 스펙으로 구성되어 있다. (아마 이걸 주로 사용하게 될것같다.)
Ingress
- 구성한 클러스터에 외부 접근을 관리해주는 api 오브젝트(규칙 모음 상자)
- 보통 Nginx Ingress 많이 사용하는듯함
- 3가지 선택 항목 제공, Do not Install / Nginx Ingress / SLB Ingress
* Do not Install: 설치 하지않겠다
* Nginx Ingress: nginx 기반의 Ingress 를 사용하겠다.
* SLB Ingress: Server Load Balance를 사용 하겠다.
Knative
- 서버 리스 솔루션의 일종
- 서버 리스 솔루션은 특정 클라우드(AWS, Alicloud, Google Cloud ... 등등) 플랫폼에 종속되어 있음 (각자 다 다름)
- 클라우드 마다 솔루션이 다 달라서 아예 쿠버에서 사용하기 쉽게 통일성있게 나온 솔루션이 knative 인걸로 확인됨
- 아마.. 어떤 클라우드에서도 knative 는 모두 동일하게 동작, 동일한 동작 방식이라고 생각됨
ServerLess
- 실제 서버가 없다는 의미가 아님
- 개발자 / 관리자가 서버 인프라에 대해 신경쓰지 않아도 된다는 의미임
- 요청이 있을때만 코드실행, 요청이 많을경우 요청에 비례하는 자원을 할당하여 동시다발적으로 처리가 가능함
- 웹소켓같은 경우 사용이 어려움
댓글