本文來自邊緣計算k3s社區
作者簡介
Cello Spring,瑞士人。從電子起步,擁有電子工程學位。爾后開始關注計算機領域,在軟件開發領域擁有多年的工作經驗。
Traefik是一個十分可靠的雲原生動態反向代理。輕量級Kubernetes發行版K3s早在去年就已經內置Traefik,將其作為集群的默認反向代理和Ingress Controller。然而,在本文成文時K3s中的默認內置Traefik版本為v1.7.14。這一版本固然也能很好地運行,但還是少了一些有用的功能。我最想用的功能是為正在使用的Ingress Route自動生成Let’s Encrypt證書。而使用Traefik 2.x版本可以獲得這一功能,甚至還有更多其他功能。那么,我們來看看如何使用K3s設置並使用新版本的Traefik。
本文的目標是設置一個新的K3s集群、安裝Traefik 2.x版本並配置一些Ingress,這些Ingress將由自動生成的Let’s Encrypt證書保護。
以下是我們將要進行的步驟:
-
在Civo上創建一個極小的K3s集群
-
將我們的域(我會使用我的虛擬域celleri.ch)指向集群IP
-
安裝Klipper LB作為我們的LoadBalancer
-
在集群上安裝Traefik v2
-
部署一個小型工作負載(whoami)到集群上
-
創建一個Traefik ingress到服務(分為有TLS termination或沒有)
-
使用Traefik 中間件以通過基本身份驗證訪問Traefik Dashboard
創建Civo集群
為此,請到Civo(civo.com/)並創建一個只有2個節點的超小型集群。如果你還沒有賬戶,可以注冊並申請KUBE100 Beta項目以使用其提供的Kubernetes產品。
需要確保我們不使用基本設置安裝Traefik(在“Architecture”選項卡上取消選擇Traefik)
大約2分鍾之后,我們將獲得以下集群:
接下來,我們需要記下master節點的IP地址並下載kubeconfig文件。在本例中,它被命名為civo-k3s-with-traefik2-kubeconfig,因為我們將集群命名為k3s-with-traefik2。為了使用kubectl從命令行中訪問該集群,我們需要將環境變量指向kubeconfig文件並將上下文更改至我們的新集群。
# set env variable with new cluster config
export KUBECONFIG=./civo-k3s-with-traefik2-kubeconfig
kubectl config use-context k3s-with-traefik2
#check the available nodes
kubectl get nodes
NAME STATUS ROLES AGE VERSION
kube-master-de56 Ready master 9m15s v1.16.3-k3s.2
kube-node-40e7 Ready 7m21s v1.16.3-k3s.2
正如我們所見,帶有1個master節點和1個worker節點的集群已經准備完畢!繼續進行下一步。
將域名Celleri.ch指向新的集群IP地址
最近一段時間,我一直使用Cloudflare(cloudflare.com/dns/)的DNS服務來處理Kubernetes。它十分可靠,有友好的用戶界面並且我使用的基本服務都是免費的。
在Cloudflare中我們應用以下設置:
本示例中,我們不想為可能用到的每個子域都創建一個CNAME條目,因此我們在此處創建一個通配符(*)條目作為CNAME。Traefik將確保稍后將流量路由到正確的位置。
安裝Klipper LB作為我們的LoadBalancer
默認情況下,K3s內置的Traefik為v1.7.x版本。默認安裝還部署了來自Rancher的內部LoadBalancer,Klipper LB。由於在設置集群時,我們沒有安裝Traefik,因此我們現在必須自己手動安裝Klipper LB。
Klipper會將自己掛接到集群節點的主機端口上,並使用端口80、443和8080。
你可以在我的Github Repo里找到我所提到的所有文件:
https://github.com/cellerich/k3s-with-traefik2
# install KlipperLB
kubectl apply -f 00-klipper-lb/klipper.yaml
# see if klipper hooked up to the host ports and is working
kc get pods --all-namespaces | grep svclb
kube-system svclb-traefik-gc8lg 3/3 Running 0 96s
kube-system svclb-traefik-pqbzb 3/3 Running 0 96s
這些Pod似乎可以與在其中運行的3個容器(每個主機端口一個容器)一起工作。接下來,我們開始安裝Traefik v2。
在集群中安裝Traefik v2
Traefik v2附帶了許多CRD,這似乎是擴展Kubernetes對象的一種新方法。我還沒有完全把精力放在這些CRD上面,但是無論如何我們都要使用它們。你可以在Traefik文檔(https://docs.traefik.io/v2.0/user-guides/crd-acme/)中找到正確的yaml文件,或者你可以使用我在Github repo上提供的01-traefik-crd/traefik-crd.yaml文件。
# apply traefik crd's
kubectl apply -f 01-traefik-crd/traefik-crd.yaml
這個命令應該會創建5個CRD。
為了讓Traefik可以做它所需要做的事情,我們需要一個clusterrole和一個clusterrolebinding。我們可以使用以下命令:
# apply clusterrole and clusterrolebinding
kubectl apply -f 01-traefik-crd/traefik-clusterrole.yaml
請注意:我們將在命名空間kube-system中為ServiceAccount進行clusterrolebinding,因為稍后我們會將流量安裝到該命名空間中。
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: traefik-ingress-controller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: traefik-ingress-controller
subjects:
- kind: ServiceAccount
name: traefik-ingress-controller
namespace: kube-system
最后,我們把Traefik Service、ServiceAccount以及Deployment部署到集群中:
kubectl apply -f 02-traefik-service/traefik.yaml
這應該為我們提供一個LoadBalancer類型的服務,該服務具有集群的master節點的外部地址:
# get traefik service
kubectl get svc -n kube-system | grep traefik
traefik LoadBalancer 192.168.211.177 185.136.232.122 80:32286/TCP,443:30108/TCP,8080:30582/TCP 3m43s
部署一個小型工作負載(whoami)到集群
現在是時候在我們的集群中創建一個服務並嘗試通過我們的Traefik代理從外部調用它。本示例中我使用的是whoami服務,它也用於Traefik文檔中的所有示例。讓我們部署它:
# deploy `whoami` in namespace `default`
kubectl apply -f 03-workload/whoami-service.yaml
#check the deployment
kubectl get pods | grep whoami
whoami-bd6b677dc-lfxbx 1/1 Running 0 5m37s
whoami-bd6b677dc-92jzj 1/1 Running 0 5m37s
好像已經可以運行了。現在要到激動人心的部分了,Traefik Ingress。
為服務創建兩個Traefik Ingress(有/沒有TLS Termination)
我們想要從外部訪問whoami服務,以讓我們最終可以定義IngressRoute對象。沒錯,那些對象是在我們之前安裝的CRD中定義的。現在它們派上用場了。我們按照以下方式部署IngressRoutes:
kubectl apply -f 03-workload/whoami-ingress-route.yaml
正如你在定義中所看到的,我們使用tls.certResolver=default指定了一個路由(附帶PathPrefix '/tls')。該certResolver在我們的02-traefik-service / traefik.yaml文件中定義。
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: ingressroute-notls
namespace: default
spec:
entryPoints:
- web
routes:
- match: Host(`celleri.ch`) && PathPrefix(`/notls`)
kind: Rule
services:
- name: whoami
port: 80
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: ingressroute-tls
namespace: default
spec:
entryPoints:
- websecure
routes:
- match: Host(`celleri.ch`) && PathPrefix(`/tls`)
kind: Rule
services:
- name: whoami
port: 80
tls:
certResolver: default
現在啟動瀏覽器並訪問地址http://celleri.ch/notls,查看即將發生的事情——pod正在響應:
那么https://celleri.ch/tls發生了什么呢?它也在正常運行,但是告訴我們第一個連接不安全。如果我們查看證書,我們就能找到原因:
為了防止因我們的安裝程序無法正常工作而使生產服務器受到許多請求的困擾,我們一開始沒有使用Let’s Encrypt,而在Traefik Service中使用staging服務器。因此,我們接下來要更改這一設置並使用生產服務器獲得一個真實的證書。
更改certresolver以使用Let’s Encrypt生產服務器
在我們定義的Traefik Deployment中,我們有以下參數:
... cropped for readability ...
spec:
serviceAccountName: traefik-ingress-controller
containers:
- name: traefik
image: traefik:v2.0
args:
- --api.insecure
- --accesslog
- --entrypoints.web.Address=:80
- --entrypoints.websecure.Address=:443
- --providers.kubernetescrd
- --certificatesresolvers.default.acme.tlschallenge
- --certificatesresolvers.default.acme.email=me@myself.com
- --certificatesresolvers.default.acme.storage=acme.json
# Please note that this is the staging Let's Encrypt server.
- --certificatesresolvers.default.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory
... cropped for readability ...
我們告訴Traefik使用tlschallenge的方法來使用名為default的certificateresolvers。此外,我們還需要提供我們的郵件和證書的存儲。我們在前文中還提到我們要使用staging caserver。
重點:在我們的部署中,我們沒有存儲提供程序或者volume。這意味着,部署重新加載后我們的證書就會消失。證書僅存在於我們的pod內存中。在生產環境中,我們必須解決這一問題並提供一個volume。
好的,讓我們注釋掉caserver行,然后重新部署Traefik deployment,看看我們是否獲得了真實的證書:
... cropped for readability ...
spec:
serviceAccountName: traefik-ingress-controller
containers:
- name: traefik
image: traefik:v2.0
args:
- --api.insecure
- --accesslog
- --entrypoints.web.Address=:80
- --entrypoints.websecure.Address=:443
- --providers.kubernetescrd
- --certificatesresolvers.default.acme.tlschallenge
- --certificatesresolvers.default.acme.email=me@myself.com
- --certificatesresolvers.default.acme.storage=acme.json
# Please note that this is the staging Let's Encrypt server.
# - --certificatesresolvers.default.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory
... cropped for readability ...
# deploy the changed file
kubectl apply -f 02-traefik-service/traefik.yaml
一會兒之后,我們將獲得一個有效證書:
在這之后,我們可以稍稍放輕松了。但是我們想更近一步,Traefik v2還有一個不錯的dashboard,可以查看正在運行的所有Ingress內容。但是我們並不希望每個人都能訪問我們的dashboard。有一些基本的身份驗證可以更好地保護我們的dashboard。
使用Traefik 中間件以通過基本身份驗證訪問Traefik Dashboard
在Traefik 2.x中引入了一個新機制——中間件,該機制在處理傳入請求時可以幫助我們完成許多任務。我們將使用basicAuth中間件來保護Traefik dashboard並將其暴露給外部。
首先,我們需要使用我們的用戶名和哈希密碼創建一個Secret,以便basicAuth 中間件在以后使用:
# create user:password file 'user'
htpasswd -c ./user cellerich
# enter password twice...
# create secret from password file
kubectl create secret generic traefik-admin --from-file user -n kube-system
確保在命名空間kube-system內創建該Secret,因為Traefik Service及其Dashboard也位於此命名空間中。
然后我們部署該中間件以及IngressRoute到我們的集群:
kubectl apply -f 04-traefik-dashboard/traefik-admin-withauth.yaml
現在,我們訪問https://traefik.celleri.ch,出現登陸提示:
使用正確的憑據,我們將訪問Traefik v2的dashboard:
並且我們會獲得許多關於我們Ingress Route的信息:
結 語
這就是教程的全部。在研究過程中,我沒有發現太多關於如何在k3s中設置Traefik v2的示例,特別是Klipper LB的部分從未被提及。這就是為什么我想向大家分享我的經驗,希望它能夠幫助到你,退一萬步來說,至少它對我的將來會有所幫助。
參考鏈接:
Github :
https://github.com/cellerich/k3s-with-traefik2
關於Rancher的Klipper LB:
https://github.com/rancher/klipper-lb
Traefik中間件文檔: