本文來自邊緣計算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
- [email protected]
- --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
- [email protected]
- --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中間件檔案:
https://docs.traefik.io/v2.0/middlewares/overview/
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/27875.html
標籤:其他
