Kubernetes 从 pod 获取入口 tls.hosts答案

【问题标题】：Kubernetes get ingress tls.hosts from podsKubernetes 从 pod 获取入口 tls.hosts
【发布时间】：2019-10-25 21:42:27
【问题描述】：

使用 Kubernetes 是否有办法从其他 pod 获取 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

所以，我想从 pod 中动态获取 myapp.mydomain.com。

【问题讨论】：

标签： kubernetes kubernetes-ingress kubernetes-service

【解决方案1】：

使用 kubernetes api 获取入口资源。创建一个角色，将其与服务帐户相关联，然后使用 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'

【讨论】：

【解决方案2】：

您可以考虑使用特定的 Service Account 从单独的 Pod 访问 Kubernetes API，通过 Pod 内的特定令牌传播利用 Bearer token 身份验证策略，根据 RBAC 规则授权执行识别目标 ServiceAccount 凭据和权限；感谢@Rodrigo Loza 的努力，他分享了一个很好的例子来指出这一点。

但是，如果您区分同一命名空间中不同服务帐户的 RBAC 权限，您可能会知道并为目标 Pod 内的相关服务帐户提供对应的credentials：

spec:
  serviceAccountName: somename

根据K8s官方文档：

创建pod的时候，如果不指定service account，就是自动分配默认服务帐户在同一命名空间。如果您获得了您创建的 pod 的原始 json 或 yaml （例如，kubectl get pods/ -o yaml），你可以看到 spec.serviceAccountName 字段已自动设置。

我还鼓励您在 K8s 文档guidelines 中了解有关身份验证策略的更多信息。

【讨论】：