我尝试通过HTTPS入口访问Kubernetes API失败,现在开始怀疑这是否完全可能?
任何直接远程访问的工作详细指南(无需使用ssh-> kubectl代理,以避免在Kubernetes节点上进行用户管理)。 :)
更新:
只是要弄清楚一点。这是前提条件下的裸机部署(NO GCE,AWZ,Azure或其他任何方式),并且有一种意图是某些环境将完全脱机(这将在获取安装软件包时增加其他问题)。
意图是要能够在通过Keycloak进行身份验证的客户端主机上使用kubectl(如果遵循分步说明,该操作也会失败)。使用SSH并随后进行kubectl的管理访问不适合进行冷杉客户端访问。因此,看来我将必须更新防火墙以公开API端口并创建NodePort服务。
设置:
[kubernetes-env]-[FW / SNAT]-[me]
防火墙/ NAT仅允许22,80和443端口访问
因此,当我在Kubernetes上设置入口时,我无法创建将443重定向到6443的防火墙规则。似乎唯一的选择是创建一个https入口,以将对“ api-kubernetes.node.lan”的访问指向kubernetes服务。端口6443。Ingress本身运行良好,我为Keycloak auth应用程序创建了一个有效的Ingress。
我已将.kube / config从主节点复制到我的计算机上,并将其放入.kube / config(Cygwin环境)中
尝试了什么:
按照指南[1]创建kube-ca签名的证书。现在,浏览器根本不显示任何内容。使用curl访问https://api-kubernetes.node.lan/api会导致输出为空(使用-v时我可以看到HTTP OK)。 Kubectl现在出现以下错误:
$ kubectl.exe version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"windows/amd64"}
Error from server: the server responded with the status code 0 but did not return more information
当尝试比较apiserver.pem和生成的证书时,我看到的唯一区别是:
apiserver.pem
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
generated.crt
X509v3 Extended Key Usage:
TLS Web Server Authentication
入口配置:
---
kind: Ingress
apiVersion: extensions/v1beta1
metadata:
name: kubernetes-api
namespace: default
labels:
app: kubernetes
annotations:
kubernetes.io/ingress.class: nginx
spec:
tls:
- secretName: kubernetes-api-cert
hosts:
- api-kubernetes.node.lan
rules:
- host: api-kubernetes.node.lan
http:
paths:
- path: "/"
backend:
serviceName: kubernetes
servicePort: 6443
答案 0 :(得分:1)
只要在kube-apiserver
名称空间中暴露kube-system
窗格,就应该能够做到。我这样尝试过:
$ kubectl -n kube-system expose pod kube-apiserver-xxxx --name=apiserver --port 6443
service/apiserver exposed
$ kubectl -n kube-system get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
apiserver ClusterIP 10.x.x.x <none> 6443/TCP 1m
...
然后转到群集计算机,并指向我的~/.kube/config
上下文IP 10.x.x.x:6443
clusters:
- cluster:
certificate-authority-data: [REDACTED]
server: https://10.x.x.x:6443
name: kubernetes
...
然后:
$ kubectl version --insecure-skip-tls-verify
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.2", GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean", BuildDate:"2018-08-07T23:17:28Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.2", GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean", BuildDate:"2018-08-07T23:08:19Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
我使用--insecure-skip-tls-verify
是因为10.x.x.x
必须在服务器证书上有效。您实际上可以这样解决:Configure AWS publicIP for a Master in Kubernetes
在您的情况下,可能有几件事:
/etc/kubernetes/pki/
下使用相同的kubeapi服务器证书答案 1 :(得分:0)
部分回答我自己的问题。
目前,我对基于令牌的身份验证感到满意:这允许具有单独的访问级别,并避免允许Shell用户使用。基于Keycloak的仪表板身份验证有效,但登录后无法注销。没有注销选项。 :D
要通过Ingress访问仪表板本身,我在某处找到了有效的重写规则:
nginx.ingress.kubernetes.io/configuration-snippet: "rewrite ^(/ui)$ $1/ui/ permanent;"
请注意,必须使用斜杠“ /”访问UI:https://server_address/ui/
答案 2 :(得分:0)
对于那些来这里只是想从另一个网络查看其kubernetes API并使用另一个主机名但又不需要将API更改为默认端口6443的端口的人来说,则不需要入口。 / p>
如果这描述了您,那么您要做的就是在您的API证书中为来自您的DNS添加其他SAN规则。 This article describes the process in detail