Loading... ## 前言 ## 首先，关于集群管理软件我在很早之前就已经听说过kubernetes了，但是一直没有尝试去使用过，恰巧最近想要搭建一个订阅链接转换的服务，所以就刚好拿搭建集群来练练手，毕竟刚好手上一台4H8G的服务器。 ## 出师不利 ## 因为我只有一台服务器，所以觉得也没必要使用k8s，于是我瞄准了k3s的搭建，在安装的开始我就碰到了一个难题。 之前对集群的一些概念了解的并不是很清楚，没想到集群的ingress controller会直接抢占端口号。 然后k3s的默认安装是会安装一个叫做traefik的ingress controller，监听主机上的80和443的端口流量并接入到集群内部，而我的服务器上正用nginx跑着我的博客网站，所以直接导致网站down了整整一天，后来才发现是集群接管流量导致的问题。 通过查看k3s的官方文档，我才找到如何关闭掉traefik自动部署的方法 一般我们安装的默认参数如下 ```bash curl -sfL https://get.k3s.io | sh - ``` 然后我们加上`--disable traefik`就可以不安装traefik 因为我想使用etcd数据库作为集群内数据管理工具，所以加上K3S_DATASTORE_ENDPOINT=etcd作为环境变量传入 最后安装参数如下 ```bash curl -sfL https://get.k3s.io | K3S_DATASTORE_ENDPOINT=etcd sh -s - --disable traefik ``` 这样就得到了一个最基本的k3s集群了 ## 安装kubernetes-dashboard ## 为了更好地管理集群，我首先尝试安装kubernetes-dashboard，从而使得集群化管理拥有一个图形化页面。 这一方面也是我碰到的第二座大山，如何将集群内的服务代理出去，虽然可以对集群内服务设置tls证书等等的操作，也可以把相关的service设置成NodePort，但是NodePort只会监听127.0.0.1这个地址，而要使得外网能够访问内部服务，必须要借助别的手段，于是我想到了nginx的反向代理。 在nginx配置好相应的端口和证书，然后进行形同如下的配置 ```conf location ^~ /xxx/ { proxy_pass https://127.0.0.1:xxxx/; # 转发规则 proxy_set_header Host $proxy_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } ``` 这样就可以访问相应域名的某个路由，然后将请求转发至`127.0.0.1:xxxx/xxx`了 这里需要注意的一点就是，举个例子如果上面的`/xxx/`是`/abc/`，域名是`www.onesnowwarrior.cn`，那么当我们访问`https://www.onesnowwarrior.cn/abc`时，就会将请求转发至`https://127.0.0.1:xxxx/`。而如果是`/abc`而不是`/abc/`，则会转发到`https://127.0.0.1:xxxx/abc`。 然后就是为了后面的目录跟随，我们不能使用`~`而是`^~`并且在`proxy_pass`写下的URL最后加上一个/ 这样配置之后，便可以使得反向代理生效。 ## rancher配置 ## rancher这一块的配置，我借助了helm进行应用管理，helm是k8s集群应用的管理工具，可以帮助快速部署，具体流程和kubernetes-dashboard其实差不多，但是当我进行反向代理配置的时候，碰到了又一个问题。就是在登录的时候，发现按照上述的反向代理配置会使得其请求`127.0.0.1`，而我们知道，在远程的本地哪里来的`127.0.0.1`拥有rancher的相关API。于是我猜想是我的反向代理有问题，于是经过了查阅无数文档，终于找到了相应的解决方法，并且还发现配置rancher的反向代理还需要配置ws相应的header ```conf location / { proxy_pass https://127.0.0.1:xxxx; # 转发规则 proxy_set_header Host $http_host; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } ``` 这里就会想，`$http_host`和`$proxy_host`有啥区别呢，为啥会导致错误的产生。 其实，主要是因为`$proxy_host`取值为`proxy_pass`中的值，然后这个值的确是本地的值，也即`127.0.0.1`，所以才使得请求判断的Host产生了错误，而`$http_host`则取自我们访问的网址的Host，从而可以得到正确的值。 ## 小结 ## 最后，经过这三座大山的跨越，我对集群网络管理，deployment，service，secret，pod，replicaset等概念有了一个比较清晰的了解，也算是得到了一定的收获吧。 并且还解决了对于我个人来讲的一个比较偏的需求（网上关于这一块基本没有什么解决方案） Last modification：March 2, 2022 © Allow specification reprint Support Appreciate the author AliPayWeChat Like 0 如果觉得我的文章对你有用，请随意赞赏
