Database용 TCP Reverse-Proxy

Database에 직접 접근하지말고 Reverse-Proxy를 둔다면 접근제어나 방화벽이 소용없게?...할 수도 있다.

방화벽 입장에서는 Proxy가 연결되는 것으로 보이니까...

 

여기서는 오라클 데이터에비스에 붙지만 어느 데이터베이스를 하더라도 상관없다. 포트랑 IP만 변경하면 거기에 맞게 붙어서 작동함.

 

Kubernetes 서비스로 Nginx를 배포하나 배포한다.. 쿠버를 사용하지않고 도커로도 conf를 동일하게 작성하면 사용할 수 있다.

 

Nginx-Proxy.yaml

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: nginx-conf
data: 
  nginx-main.conf: |
    user  nginx;
    worker_processes  auto;

    error_log  /var/log/nginx/error.log notice;
    pid        /var/run/nginx.pid;

    events {
        worker_connections  1024;
    }

    stream {
      upstream oracle_backend {
          server <오라클데이터베이스IP>:1621;
      }
      server {
          listen 1621;
          proxy_pass oracle_backend;
      }
    }
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        imagePullPolicy: Always
        ports:
        - containerPort: 1621
          protocol: TCP
        volumeMounts:
        - mountPath: /etc/nginx/nginx.conf
          readOnly: true
          name: nginx-main-conf-test
          subPath: nginx.conf
      volumes:
      - name: nginx-main-conf-test
        configMap:
          name: nginx-conf
          items:
            - key: nginx-main.conf
              path: nginx.conf
---
kind: Service
apiVersion: v1
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - port: 1621
    protocol: TCP
    targetPort: 1621
    nodePort: 31621

 

위의 YAML은 configmap, deployment, service로 구성되어있다.

configmap은 nginx proxy를 구성한 설정값이 들어있다.

Nginx 서버에 1621포트로 TCP 프로토콜로 요청이 들어오면

해당 요청을 Oracle DB로 모두 Proxy Pass를 하는 설정이다.

Depolyment는 configmap을 통하여 nginx Pod를 배포하며

Service는 NodePort 타입으로 구성하여 쿠버네티스의 노드의 IP:31621로 nginx proxy server를 호출할 수 있다. (nodeport는 3만번대 포트만 사용할 수 있기에 31621로 지정)

현재 구성된 노드의 IP는 10.140.11.9, 10.140.11.10 2개 노드가 존재한다.

둘 중 무엇을 써도 상관없다.

 

Local —(SSLVPN, 31621 port)→ 10.140.11.9(Nginx-Proxy) —(IPSecVPN, 1621 port)→ Oracle Database

 

 

**** 쿠버네티스 노드 IP가 변경되는 작업이 발생한다면 (노드를 없애고 새로 띄우거나 등등) 설정한 접속 10.140.11.9가 URL이 변경될 가능성이 높음. 그러니 쿠버네티스 클러스터 내부에서는 NodePort 주소를 절대 사용하지 말고 그냥 로컬에서만 사용해야함. 쿠버클러스터 내부에서는 내부DNS용 네이밍을 사용하자.**

<aside> 🚨 Kubernetes Internal Domain Name Example

In Kubernetes, the internal domain name is typically determined by the cluster's DNS service. The domain name for internal communication between Kubernetes services is based on the service name and the namespace in which the service is deployed.

Let's assume you have a service named "my-service" running in the "my-namespace" namespace. The internal domain name for this service would be:

arduinoCopy code
my-service.my-namespace.svc.cluster.local

In the above example, "svc.cluster.local" is the default domain for Kubernetes services within a cluster.

Please note that this domain name assumes you are using the default Kubernetes DNS service. If you have a different DNS configuration or have customized your cluster's DNS, the domain name may vary.

</aside>

Reference

TCP and UDP Load Balancing with NGINX: Tips and Tricks

TCP and UDP Load Balancing with NGINX: Tips and Tricks