Kubernetes получают доступ tls.hosts от стручков - PullRequest
Новая
       97

Kubernetes получают доступ tls.hosts от стручков

0 голосов
/ 26 октября 2019

Используя Kubernetes, есть ли способ из других модулей получить значение ingress.spec.tls.hosts без использования kubectl (DNS, ENVVAR, OTHER) ?

Я знаю, что могу сделать:

# in other pod
dig +short my-app.default.svc.cluster.local
172.20.203.19

echo $MY_APP_SERVICE_HOST
172.20.203.19

echo $MY_APP_SERVICE_PORT
3000

Или: 

# in other pod
dig +short SRV my-app.default.svc.cluster.local
0 100 3000 my-app.default.svc.cluster.local.

Но я действительно хочу подключиться к внешнему балансировщику нагрузки my-app, который имеет входное определение: 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    kubernetes.io/ingress.class: "traefik"
    kubernetes.io/tls-acme: "true"
spec:
  tls:
  - hosts:
    - myapp.mydomain.com
  rules:
  - host: myapp.mydomain.com
    http:
      paths:
      - path: /
        backend:
          serviceName: my-app
          servicePort: http

Итак, я хочу динамически получать myapp.mydomain.com из стручков.

Ответы [ 2 ]

1 голос
/ 26 октября 2019

Используйте API kubernetes, чтобы получить входной ресурс. Создайте роль, свяжите ее с учетной записью службы, а затем перечислите свои входы, например, с помощью curl. Пример ниже для пространства имен по умолчанию и учетной записи службы: 

---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ingress-clusterrole
  namespace: default
rules:
- apiGroups: ["*"] # "" indicates the core API group
  resources: ["ingresses"]
  verbs: ["*"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ingress-clusterrolebinding
  namespace: default
roleRef:
  name: ingress-clusterrole
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
subjects:
  - name: default
    namespace: default
    kind: ServiceAccount

curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization: Bearer $(cat /var/run/secrets/kubernet
es.io/serviceaccount/token)" -H "Accept: application/json" -H "Content-Type: application/json" https://kubernetes.default.svc/ap
is/extensions/v1beta1/namespaces/default/ingresses | jq '.items'
0 голосов
/ 29 октября 2019

Вы можете рассмотреть доступ к API Kubernetes из отдельного Pod, используя конкретную учетную запись службы , используя маркер на предъявителя стратегию аутентификации через распространение конкретного токена внутри Pod, определяяцелевые ServiceAccount учетные данные и разрешения в соответствии с RBAC правилами авторизации;спасибо @Rodrigo Loza за его усилия по обмену хорошим примером, указывающим на это.

Однако, если вы различаете разрешения RBAC для разных учетных записей служб в одном и том же пространстве имен, вы можете знать и предоставить соответствующие учетные данные для соответствующей учетной записи службы внутри целевого модуля: 

spec:
  serviceAccountName: somename

Согласно официальной документации K8s:

При создании модуля, если вы не укажетеслужебной учетной записи, ей автоматически назначается служебная учетная запись по умолчанию в том же пространстве имен. Если вы получили необработанный json или yaml для созданного вами модуля (например, kubectl get pods / -o yaml ), вы увидите, что поле spec.serviceAccountName было автоматическиset.

Я также призываю вас узнать больше о стратегиях аутентификации в документации по K8s Guidelines .

...