nginx(tls 인증서)+webapp을 포함한 도커를 kubernetes에서 사용하려면 

k8s 443(ingress)-> 443(service) -> 443 (docker)로 적용되야 하는데.. 이는 처음부터 잘 작동되지 않는다. k8s ingress와 service에 tls인증서가 없고 docker 단에서 처리되야 하기에... 이슈가 있다.

만약 이를 동작하게 하려면 ssl paththough라는 기술을 사용해야 한다.

kubernetes (쿠버네티스) ssl passthrough 관련 정보

https://medium.com/ibm-cloud/how-to-enable-ssl-passthrough-in-ibm-cloud-private-d33e5d442d96

https://github.com/kubernetes/ingress-nginx/issues/803

https://www.thomas-zuehlke.de/2019/02/setup-kubernetes-ingress-with-ssl-passthrough/

helm 차트 삭제 (helm delete) 삭제하는 예시

--purge를 해야 깔끔히 정리한다 .

helm 차트 추가하기(with 사설 저장소 추가)

맥북에서 도커 네트워크(brider)를 생성하는 예시이다. 

정상적으로 드라이버가 생겼는지 확인한다.

생성된 네트워크(bridge)를 사용하는 컨테이너를 실행한다.

두 번 커맨드를 사용해 생성된 네트워크(bridge)를 사용할 수 있다.

내부 ip를 확인해본다.

PC에서 공용 Ip를 찾는 방법이다.

보통은 eth0을 찾기 위해 ifconfig 또는 ip address list를 실행하는데, 도커나 가상 네트워크 등을 설치/설정하면서 복잡해질 때가 있다.

브라우져에서 https://ifconfig.co 를 실행하거나 

curl https://ifconfig.co를 실행한다.

플랫 네트워크(flat network) - 비용, 유지 관리, 관리를 줄이기 위한 컴퓨터 네트워크 설계 방식으로서 장치를 별도의 스위치 대신 단일 스위치에 연결하여 컴퓨터 네트워크의 라우터와 스위치 개수를 줄이는 방식이다. 즉 중간 단계 없이 직접 통신할 수 있는 방식을 말한다. 따라서 계층적 네트워크(hierarchy network)와 달리 플랫 네트워크는 스위치를 사용해 물리적으로 분리되지 않는다

플랫 네트워크의 예로 도커의 브릿지(bridge)를 예로 들 수 있다.

도커의 브릿지는 컨테이너 간의 플랫 네트워크(flat network)를 생성하고 요청을 외부에 외부 연결로 전달한다.

kubernetes의 Service.spec.type의 기본값은 ClusterIP이다. 

clusterip는 iptables 기반이다.  k8s 서비스를 클러스터 내부 IP에 노출하고 클러스터 내에서만 서비스에 도달할 수 있게 한다. 

(참고 : kubernetes)

이외 3가지가 더 있다. 

Ingress를 사용하지 않으면 Nodeport를 사용한다. 

하지만 개인적으로 Ingress를 두는 것이 운영하는 데 훨씬 도움이 되는 것 같다. 

LoadBalancer는 LBaaS로 사용자가 로드 밸런서를 추가할 수 있는 형태이다.

아마존의 경우는 아래와 같이 사용할 수 있다. 

https://aws.amazon.com/ko/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/

https://github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md

실제 사용 예를 살펴본다. 아래 ingress-nginx에 잘 나와 있다. 

https://github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md

type이 LoadBalancer 타입일 경우에는 어떻게 설정되어 있는지 확인할 수 있다. 

aws L4 LB를 사용하려면 다음과 같이 사용한다. 

https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/aws/service-l4.yaml

kind: Service
apiVersion: v1
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  annotations:
    # Enable PROXY protocol
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
    # Ensure the ELB idle timeout is less than nginx keep-alive timeout. By default,
    # NGINX keep-alive is set to 75s. If using WebSockets, the value will need to be
    # increased to '3600' to avoid any potential issues.
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  ports:
    - name: http
      port: 80
      targetPort: http
    - name: https
      port: 443
      targetPort: https

---

kind: Service
apiVersion: v1
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  annotations:
    # replace with the correct value of the generated certificate in the AWS console
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:us-west-2:XXXXXXXX:certificate/XXXXXX-XXXXXXX-XXXXXXX-XXXXXXXX"
    # the backend instances are HTTP
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
    # Map port 443
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "https"
    # Ensure the ELB idle timeout is less than nginx keep-alive timeout. By default,
    # NGINX keep-alive is set to 75s. If using WebSockets, the value will need to be
    # increased to '3600' to avoid any potential issues.
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  ports:
    - name: http
      port: 80
      targetPort: http
    - name: https
      port: 443
      targetPort: http

---

마지막으로 EnternalName은 CoreDNS에서 지원하는 CNAME 값이다. 

지금까지 설명한 내용은 다음 문서에 있다. 

https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

• ClusterIP: Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default ServiceType.
• NodePort: Exposes the Service on each Node’s IP at a static port (the NodePort). A ClusterIP Service, to which the NodePort Service routes, is automatically created. You’ll be able to contact the NodePort Service, from outside the cluster, by requesting <NodeIP>:<NodePort>.
• LoadBalancer: Exposes the Service externally using a cloud provider’s load balancer. NodePort and ClusterIP Services, to which the external load balancer routes, are automatically created.

• ExternalName: Maps the Service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record

  with its value. No proxying of any kind is set up.