Кубернетес Django Рестраммация на ГКЕ - PullRequest
Новая
       15

Кубернетес Django Рестраммация на ГКЕ

0 голосов
/ 16 января 2020

Я пытался получить доступ через внешний ip от балансировщика нагрузки. Но я не могу подключиться к своему браузеру через этот ip.

Мне отказано в соединении через порт 80. Я не знаю, неверен ли мой файл yaml или его конфигурация на моем балансировщике нагрузки

Я успешно собрал свой docker образ с помощью файла needs.txt и загрузил его в корзину из GKE, чтобы вытащить образ docker в Кубернетес.

Я развернул образ с помощью команды: kubectl create -f <filename>.yaml

со следующим файлом yaml: 

# [START kubernetes_deployment]
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: example
  labels:
    app: example
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
      - name: faxi
        image: gcr.io/<my_id_stands_here>/<bucketname>
        command: ["python3", "manage.py", "runserver"]
        env:
            # [START cloudsql_secrets]
            - name: DATABASE_USER
              valueFrom:
                secretKeyRef:
                  name: cloudsql
                  key: username
            - name: DATABASE_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: cloudsql
                  key: password
            # [END cloudsql_secrets]
        ports:
        - containerPort: 8080

      # [START proxy_container]
      - image: b.gcr.io/cloudsql-docker/gce-proxy:1.05
        name: cloudsql-proxy
        command: ["/cloud_sql_proxy", "--dir=/cloudsql",
                  "-instances=<I put here my instance name inside>",
                  "-credential_file=<my_credential_file"]
        volumeMounts:
          - name: cloudsql-oauth-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: ssl-certs
            mountPath: /etc/ssl/certs
          - name: cloudsql
            mountPath: /cloudsql
      # [END proxy_container] 
      # [START volumes]
      volumes:
        - name: cloudsql-oauth-credentials
          secret:
            secretName: cloudsql-oauth-credentials
        - name: ssl-certs
          hostPath:
            path: /etc/ssl/certs
        - name: cloudsql
          emptyDir:
      # [END volumes]        
# [END kubernetes_deployment]

---

# [START service]
apiVersion: v1
kind: Service
metadata:
  name: example
  labels:
    app: example
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: example
# [END service]

Работает нормально. Вывод ниже: kubectl get pods

NAME                    READY   STATUS    RESTARTS   AGE
mypodname.            2/2     Running             0           21h

и kubectl get services

NAME         TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
example      LoadBalancer   10.xx.xxx.xxx   34.xx.xxx.xxx   80:30833/TCP   21h
kubernetes   ClusterIP      10.xx.xxx.x     <none>          443/TCP        23h

kubectl describe services example дает мне следующий вывод 

Name:                     example
Namespace:                default
Labels:                   app=example
Annotations:              <none>
Selector:                 app=example
Type:                     LoadBalancer
IP:                       10.xx.xxx.xxx
LoadBalancer Ingress:     34.xx.xxx.xxx
Port:                     <unset>  80/TCP
TargetPort:               8080/TCP
NodePort:                 <unset>  30833/TCP
Endpoints:                10.xx.x.xx:8080
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

Но я не могу подключиться к своему API остальных через curl или браузер. Я пытаюсь подключиться к <external_ip>:80 и получить a connection refused on this port

Я отсканировал внешний ip с помощью Nmap , и он показывает, что порт 80 закрыт. Но я не уверен, если это причина. Мой вывод nmap: 

PORT     STATE  SERVICE
80/tcp   closed http
554/tcp  open   rtsp
7070/tcp open   realserver

Спасибо за вашу помощь, ребята

1 Ответ

0 голосов
/ 17 января 2020

Создайте правило входного брандмауэра, чтобы разрешить трафик c через порт 30833 для всех узлов, поскольку это должно решить проблему.

...