2. 程式人生 > >(三)認證授權和服務發現_Kubernetes中文社群

(三)認證授權和服務發現_Kubernetes中文社群

阿新 • • 發佈：2018-12-27

1. 理解認證授權

1.1 為什麼要認證

想理解認證，我們得從認證解決什麼問題、防止什麼問題的發生入手。
防止什麼問題呢？是防止有人入侵你的叢集，root你的機器後讓我們叢集依然安全嗎？不是吧，root都到手了，那就為所欲為，防不勝防了。
其實網路安全本身就是為了解決在某些假設成立的條件下如何防範的問題。比如一個非常重要的假設就是兩個節點或者ip之間的通訊網路是不可信任的，可能會被第三方竊取，也可能會被第三方篡改。就像我們上學時候給心儀的女孩傳紙條，傳送的過程可能會被別的同學偷看，甚至內容可能會從我喜歡你修改成我不喜歡你了。當然這種假設不是隨便想出來的，而是從網路技術現狀和實際發生的問題中發現、總結出來的。kubernetes的認證也是從這個問題出發來實現的。

1.2 概念梳理

為了解決上面說的問題，kubernetes並不需要自己想辦法，畢竟是網路安全層面的問題，是每個服務都會遇到的問題，業內也有成熟的方案來解決。這裡我們一起了解一下業內方案和相關的概念。

1.3 什麼是授權

授權的概念就簡單多了，就是什麼人具有什麼樣的許可權，一般通過角色作為紐帶把他們組合在一起。也就是一個角色一邊擁有多種許可權，一邊擁有多個人。這樣就把人和許可權建立了一個關係。

2. kubernetes的認證授權

Kubernetes叢集的所有操作基本上都是通過kube-apiserver這個元件進行的，它提供HTTP RESTful形式的API供叢集內外客戶端呼叫。需要注意的是：認證授權過程只存在HTTPS形式的API中。也就是說，如果客戶端使用HTTP連線到kube-apiserver，那麼是不會進行認證授權的。所以說，可以這麼設定，在叢集內部元件間通訊使用HTTP，叢集外部就使用HTTPS，這樣既增加了安全性，也不至於太複雜。
對APIServer的訪問要經過的三個步驟，前面兩個是認證和授權，第三個是 Admission Control，它也能在一定程度上提高安全性，不過更多是資源管理方面的作用。

2.1 kubernetes的認證

kubernetes提供了多種認證方式，比如客戶端證書、靜態token、靜態密碼檔案、ServiceAccountTokens等等。你可以同時使用一種或多種認證方式。只要通過任何一個都被認作是認證通過。下面我們就認識幾個常見的認證方式。

  • 客戶端證書認證
    客戶端證書認證叫作TLS雙向認證，也就是伺服器客戶端互相驗證證書的正確性，在都正確的情況下協調通訊加密方案。
    為了使用這個方案，api-server需要用–client-ca-file選項來開啟。
  • 引導Token
    當我們有非常多的node節點時，手動為每個node節點配置TLS認證比較麻煩，這時就可以用到引導token的認證方式，前提是需要在api-server開啟 experimental-bootstrap-token-auth 特性，客戶端的token資訊與預先定義的token匹配認證通過後，自動為node頒發證書。當然引導token是一種機制，可以用到各種場景中。
  • Service Account Tokens 認證
    有些情況下，我們希望在pod內部訪問api-server，獲取叢集的資訊，甚至對叢集進行改動。針對這種情況，kubernetes提供了一種特殊的認證方式：Service Account。 Service Account 和 pod、service、deployment 一樣是 kubernetes 叢集中的一種資源，使用者也可以建立自己的 Service Account。
    ServiceAccount 主要包含了三個內容：namespace、Token 和 CA。namespace 指定了 pod 所在的 namespace，CA 用於驗證 apiserver 的證書，token 用作身份驗證。它們都通過 mount 的方式儲存在 pod 的檔案系統中。

2.2 kubernetes的授權

在Kubernetes1.6版本中新增角色訪問控制機制（Role-Based Access，RBAC）讓叢集管理員可以針對特定使用者或服務賬號的角色，進行更精確的資源訪問控制。在RBAC中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。在一個組織中，角色是為了完成各種工作而創造，使用者則依據它的責任和資格來被指派相應的角色，使用者可以很容易地從一個角色被指派到另一個角色。
目前 Kubernetes 中有一系列的鑑權機制，因為Kubernetes社群的投入和偏好，相對於其它鑑權機制而言，RBAC是更好的選擇。具體RBAC是如何體現在kubernetes系統中的我們會在後面的部署中逐步的深入瞭解。

2.3 kubernetes的AdmissionControl

AdmissionControl – 准入控制本質上為一段准入程式碼，在對kubernetes api的請求過程中，順序為：先經過認證 & 授權，然後執行准入操作，最後對目標物件進行操作。這個准入程式碼在api-server中，而且必須被編譯到二進位制檔案中才能被執行。
在對叢集進行請求時，每個准入控制程式碼都按照一定順序執行。如果有一個准入控制拒絕了此次請求，那麼整個請求的結果將會立即返回，並提示使用者相應的error資訊。
常用元件（控制程式碼）如下：

  • AlwaysAdmit：允許所有請求
  • AlwaysDeny：禁止所有請求，多用於測試環境
  • ServiceAccount：它將serviceAccounts實現了自動化，它會輔助serviceAccount做一些事情，比如如果pod沒有serviceAccount屬性，它會自動新增一個default，並確保pod的serviceAccount始終存在
  • LimitRanger：他會觀察所有的請求，確保沒有違反已經定義好的約束條件，這些條件定義在namespace中LimitRange物件中。如果在kubernetes中使用LimitRange物件，則必須使用這個外掛。
  • NamespaceExists：它會觀察所有的請求，如果請求嘗試建立一個不存在的namespace，則這個請求被拒絕。

3. 環境準備

3.1 停止原有kubernetes相關服務

開始之前我們要先把基礎版本的叢集停掉，包括service，deployments，pods以及執行的所有kubernetes元件

#刪除services
$ kubectl delete services nginx-service

#刪除deployments
$ kubectl delete deploy kubernetes-bootcamp
$ kubectl delete deploy nginx-deployment

#停掉worker節點的服務
$ service kubelet stop && rm -fr /var/lib/kubelet/*
$ service kube-proxy stop && rm -fr /var/lib/kube-proxy/*
$ service kube-calico stop

#停掉master節點的服務
$ service kube-calico stop
$ service kube-scheduler stop
$ service kube-controller-manager stop
$ service kube-apiserver stop
$ service etcd stop && rm -fr /var/lib/etcd/*

3.2 生成配置（所有節點）

跟基礎環境搭建一樣，我們需要生成kubernetes-with-ca的所有相關配置檔案

$ cd ~/kubernetes-starter
#按照配置檔案的提示編輯好配置
$ vi config.properties
#生成配置
$ ./gen-config.sh with-ca

3.3 安裝cfssl（所有節點）

cfssl是非常好用的CA工具，我們用它來生成證書和祕鑰檔案
安裝過程比較簡單，如下：

#下載
$ wget -q --show-progress --https-only --timestamping \
  https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 \
  https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
#修改為可執行許可權
$ chmod +x cfssl_linux-amd64 cfssljson_linux-amd64
#移動到bin目錄
$ mv cfssl_linux-amd64 /usr/local/bin/cfssl
$ mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
#驗證
$ cfssl version

3.4 生成根證書（主節點）

根證書是證書信任鏈的根，各個元件通訊的前提是有一份大家都信任的證書（根證書），每個人使用的證書都是由這個根證書籤發的。

#所有證書相關的東西都放在這
$ mkdir -p /etc/kubernetes/ca
#準備生成證書的配置檔案
$ cp ~/kubernetes-starter/target/ca/ca-config.json /etc/kubernetes/ca
$ cp ~/kubernetes-starter/target/ca/ca-csr.json /etc/kubernetes/ca
#生成證書和祕鑰
$ cd /etc/kubernetes/ca
$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca
#生成完成後會有以下檔案（我們最終想要的就是ca-key.pem和ca.pem，一個祕鑰，一個證書）
$ ls
ca-config.json  ca.csr  ca-csr.json  ca-key.pem  ca.pem

4. 改造etcd

4.1 準備證書

etcd節點需要提供給其他服務訪問，就要驗證其他服務的身份，所以需要一個標識自己監聽服務的server證書，當有多個etcd節點的時候也需要client證書與etcd叢集其他節點互動，當然也可以client和server使用同一個證書因為它們本質上沒有區別。

#etcd證書放在這
$ mkdir -p /etc/kubernetes/ca/etcd
#準備etcd證書配置
$ cp ~/kubernetes-starter/target/ca/etcd/etcd-csr.json /etc/kubernetes/ca/etcd/
$ cd /etc/kubernetes/ca/etcd/
#使用根證書(ca.pem)簽發etcd證書
$ cfssl gencert \
        -ca=/etc/kubernetes/ca/ca.pem \
        -ca-key=/etc/kubernetes/ca/ca-key.pem \
        -config=/etc/kubernetes/ca/ca-config.json \
        -profile=kubernetes etcd-csr.json | cfssljson -bare etcd
#跟之前類似生成三個檔案etcd.csr是個中間證書請求檔案，我們最終要的是etcd-key.pem和etcd.pem
$ ls
etcd.csr  etcd-csr.json  etcd-key.pem  etcd.pem

4.2 改造etcd服務

建議大家先比較一下增加認證的etcd配置與原有配置的區別，做到心中有數。
可以使用命令比較：

$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/etcd.service kubernetes-with-ca/master-node/etcd.service

更新etcd服務：

$ cp ~/kubernetes-starter/target/master-node/etcd.service /lib/systemd/system/
$ systemctl daemon-reload
$ service etcd start
#驗證etcd服務（endpoints自行替換）
$ ETCDCTL_API=3 etcdctl \
  --endpoints=https://192.168.1.102:2379  \
  --cacert=/etc/kubernetes/ca/ca.pem \
  --cert=/etc/kubernetes/ca/etcd/etcd.pem \
  --key=/etc/kubernetes/ca/etcd/etcd-key.pem \
  endpoint health

5. 改造api-server

5.1 準備證書

#api-server證書放在這，api-server是核心，資料夾叫kubernetes吧，如果想叫apiserver也可以，不過相關的地方都需要修改哦
$ mkdir -p /etc/kubernetes/ca/kubernetes
#準備apiserver證書配置
$ cp ~/kubernetes-starter/target/ca/kubernetes/kubernetes-csr.json /etc/kubernetes/ca/kubernetes/
$ cd /etc/kubernetes/ca/kubernetes/
#使用根證書(ca.pem)簽發kubernetes證書
$ cfssl gencert \
        -ca=/etc/kubernetes/ca/ca.pem \
        -ca-key=/etc/kubernetes/ca/ca-key.pem \
        -config=/etc/kubernetes/ca/ca-config.json \
        -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes
#跟之前類似生成三個檔案kubernetes.csr是個中間證書請求檔案，我們最終要的是kubernetes-key.pem和kubernetes.pem
$ ls
kubernetes.csr  kubernetes-csr.json  kubernetes-key.pem  kubernetes.pem

5.2 改造api-server服務

檢視diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/master-node/kube-apiserver.service kubernetes-with-ca/master-node/kube-apiserver.service

生成token認證檔案

#生成隨機token
$ head -c 16 /dev/urandom | od -An -t x | tr -d ' '
8afdf3c4eb7c74018452423c29433609

#按照固定格式寫入token.csv，注意替換token內容
$ echo "8afdf3c4eb7c74018452423c29433609,kubelet-bootstrap,10001,\"system:kubelet-bootstrap\"" > /etc/kubernetes/ca/kubernetes/token.csv

更新api-server服務

$ cp ~/kubernetes-starter/target/master-node/kube-apiserver.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kube-apiserver start

#檢查日誌
$ journalctl -f -u kube-apiserver

6. 改造controller-manager

controller-manager一般與api-server在同一臺機器上，所以可以使用非安全埠與api-server通訊，不需要生成證書和私鑰。

6.1 改造controller-manager服務

檢視diff

$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/kube-controller-manager.service kubernetes-with-ca/master-node/kube-controller-manager.service

更新controller-manager服務

$ cp ~/kubernetes-starter/target/master-node/kube-controller-manager.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kube-controller-manager start

#檢查日誌
$ journalctl -f -u kube-controller-manager

7. 改造scheduler

scheduler一般與apiserver在同一臺機器上，所以可以使用非安全埠與apiserver通訊。不需要生成證書和私鑰。

7.1 改造scheduler服務

檢視diff
比較會發現兩個檔案並沒有區別，不需要改造

$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/kube-scheduler.service kubernetes-with-ca/master-node/kube-scheduler.service

啟動服務

$ service kube-scheduler start
#檢查日誌
$ journalctl -f -u kube-scheduler

8. 改造kubectl

8.1 準備證書

#kubectl證書放在這，由於kubectl相當於系統管理員，我們使用admin命名
$ mkdir -p /etc/kubernetes/ca/admin
#準備admin證書配置 - kubectl只需客戶端證書，因此證書請求中 hosts 欄位可以為空
$ cp ~/kubernetes-starter/target/ca/admin/admin-csr.json /etc/kubernetes/ca/admin/
$ cd /etc/kubernetes/ca/admin/
#使用根證書(ca.pem)簽發admin證書
$ cfssl gencert \
        -ca=/etc/kubernetes/ca/ca.pem \
        -ca-key=/etc/kubernetes/ca/ca-key.pem \
        -config=/etc/kubernetes/ca/ca-config.json \
        -profile=kubernetes admin-csr.json | cfssljson -bare admin
#我們最終要的是admin-key.pem和admin.pem
$ ls
admin.csr  admin-csr.json  admin-key.pem  admin.pem

8.2 配置kubectl

#指定apiserver的地址和證書位置（ip自行修改）
$ kubectl config set-cluster kubernetes \
        --certificate-authority=/etc/kubernetes/ca/ca.pem \
        --embed-certs=true \
        --server=https://192.168.1.102:6443
#設定客戶端認證引數，指定admin證書和祕鑰
$ kubectl config set-credentials admin \
        --client-certificate=/etc/kubernetes/ca/admin/admin.pem \
        --embed-certs=true \
        --client-key=/etc/kubernetes/ca/admin/admin-key.pem
#關聯使用者和叢集
$ kubectl config set-context kubernetes \
        --cluster=kubernetes --user=admin
#設定當前上下文
$ kubectl config use-context kubernetes

#設定結果就是一個配置檔案，可以看看內容
$ cat ~/.kube/config

驗證master節點

#可以使用剛配置好的kubectl檢視一下元件狀態
$ kubectl get componentstatus
NAME                 STATUS    MESSAGE              ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health": "true"}

9. 改造calico-node

9.1 準備證書

後續可以看到calico證書用在四個地方：

  • calico/node 這個docker 容器執行時訪問 etcd 使用證書
  • cni 配置檔案中，cni 外掛需要訪問 etcd 使用證書
  • calicoctl 操作叢集網路時訪問 etcd 使用證書
  • calico/kube-controllers 同步叢集網路策略時訪問 etcd 使用證書 
    #calico證書放在這
$ mkdir -p /etc/kubernetes/ca/calico
#準備calico證書配置 - calico只需客戶端證書，因此證書請求中 hosts 欄位可以為空
$ cp ~/kubernetes-starter/target/ca/calico/calico-csr.json /etc/kubernetes/ca/calico/
$ cd /etc/kubernetes/ca/calico/
#使用根證書(ca.pem)簽發calico證書
$ cfssl gencert \
    -ca=/etc/kubernetes/ca/ca.pem \
    -ca-key=/etc/kubernetes/ca/ca-key.pem \
    -config=/etc/kubernetes/ca/ca-config.json \
    -profile=kubernetes calico-csr.json | cfssljson -bare calico
#我們最終要的是calico-key.pem和calico.pem
$ ls
calico.csr  calico-csr.json  calico-key.pem  calico.pem

9.2 改造calico服務

檢視diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/all-node/kube-calico.service kubernetes-with-ca/all-node/kube-calico.service

通過diff會發現，calico多了幾個認證相關的檔案：
/etc/kubernetes/ca/ca.pem
/etc/kubernetes/ca/calico/calico.pem
/etc/kubernetes/ca/calico/calico-key.pem
由於calico服務是所有節點都需要啟動的，大家需要把這幾個檔案拷貝到每臺伺服器上

更新calico服務

$ cp ~/kubernetes-starter/target/all-node/kube-calico.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kube-calico start

#驗證calico（能看到其他節點的列表就對啦）
$ calicoctl node status

10. 改造kubelet

我們這裡讓kubelet使用引導token的方式認證，所以認證方式跟之前的元件不同，它的證書不是手動生成，而是由工作節點TLS BootStrap 向api-server請求，由主節點的controller-manager 自動簽發。

10.1 建立角色繫結（主節點）

引導token的方式要求客戶端向api-server發起請求時告訴他你的使用者名稱和token，並且這個使用者是具有一個特定的角色：system:node-bootstrapper，所以需要先將 bootstrap token 檔案中的 kubelet-bootstrap 使用者賦予這個特定角色，然後 kubelet 才有許可權發起建立認證請求。
在主節點執行下面命令

#可以通過下面命令查詢clusterrole列表
$ kubectl -n kube-system get clusterrole

#可以回顧一下token檔案的內容
$ cat /etc/kubernetes/ca/kubernetes/token.csv
8afdf3c4eb7c74018452423c29433609,kubelet-bootstrap,10001,"system:kubelet-bootstrap"

#建立角色繫結（將使用者kubelet-bootstrap與角色system:node-bootstrapper繫結）
$ kubectl create clusterrolebinding kubelet-bootstrap \
         --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap

10.2 建立bootstrap.kubeconfig（工作節點）

這個配置是用來完成bootstrap token認證的，儲存了像使用者，token等重要的認證資訊，這個檔案可以藉助kubectl命令生成：（也可以自己寫配置）

#設定叢集引數(注意替換ip)
$ kubectl config set-cluster kubernetes \
        --certificate-authority=/etc/kubernetes/ca/ca.pem \
        --embed-certs=true \
        --server=https://192.168.1.102:6443 \
        --kubeconfig=bootstrap.kubeconfig
#設定客戶端認證引數(注意替換token)
$ kubectl config set-credentials kubelet-bootstrap \
        --token=8afdf3c4eb7c74018452423c29433609 \
        --kubeconfig=bootstrap.kubeconfig
#設定上下文
$ kubectl config set-context default \
        --cluster=kubernetes \
        --user=kubelet-bootstrap \
        --kubeconfig=bootstrap.kubeconfig
#選擇上下文
$ kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
#將剛生成的檔案移動到合適的位置
$ mv bootstrap.kubeconfig /etc/kubernetes/

10.3 準備cni配置

檢視diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/worker-node/10-calico.conf kubernetes-with-ca/worker-node/10-calico.conf

copy配置

$ cp ~/kubernetes-starter/target/worker-node/10-calico.conf /etc/cni/net.d/

10.4 改造kubelet服務

檢視diff

$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/worker-node/kubelet.service kubernetes-with-ca/worker-node/kubelet.service

更新服務

$ cp ~/kubernetes-starter/target/worker-node/kubelet.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kubelet start

#啟動kubelet之後到master節點允許worker加入(批准worker的tls證書請求)
#--------*在主節點執行*---------
$ kubectl get csr|grep 'Pending' | awk '{print $1}'| xargs kubectl certificate approve
#-----------------------------

#檢查日誌
$ journalctl -f -u kubelet

11. 改造kube-proxy

11.1 準備證書

#proxy證書放在這
$ mkdir -p /etc/kubernetes/ca/kube-proxy

#準備proxy證書配置 - proxy只需客戶端證書，因此證書請求中 hosts 欄位可以為空。
#CN 指定該證書的 User 為 system:kube-proxy，預定義的 ClusterRoleBinding system:node-proxy 將User system:kube-proxy 與 Role system:node-proxier 繫結，授予了呼叫 kube-api-server proxy的相關 API 的許可權
$ cp ~/kubernetes-starter/target/ca/kube-proxy/kube-proxy-csr.json /etc/kubernetes/ca/kube-proxy/
$ cd /etc/kubernetes/ca/kube-proxy/

#使用根證書(ca.pem)簽發calico證書
$ cfssl gencert \
        -ca=/etc/kubernetes/ca/ca.pem \
        -ca-key=/etc/kubernetes/ca/ca-key.pem \
        -config=/etc/kubernetes/ca/ca-config.json \
        -profile=kubernetes kube-proxy-csr.json | cfssljson -bare kube-proxy
#我們最終要的是kube-proxy-key.pem和kube-proxy.pem
$ ls
kube-proxy.csr  kube-proxy-csr.json  kube-proxy-key.pem  kube-proxy.pem

11.2 生成kube-proxy.kubeconfig配置

#設定叢集引數（注意替換ip）
$ kubectl config set-cluster kubernetes \
        --certificate-authority=/etc/kubernetes/ca/ca.pem \
        --embed-certs=true \
        --server=https://192.168.1.102:6443 \
        --kubeconfig=kube-proxy.kubeconfig
#置客戶端認證引數
$ kubectl config set-credentials kube-proxy \
        --client-certificate=/etc/kubernetes/ca/kube-proxy/kube-proxy.pem \
        --client-key=/etc/kubernetes/ca/kube-proxy/kube-proxy-key.pem \
        --embed-certs=true \
        --kubeconfig=kube-proxy.kubeconfig
#設定上下文引數
$ kubectl config set-context default \
        --cluster=kubernetes \
        --user=kube-proxy \
        --kubecon

相關推薦

(三)認證授權和服務發現_Kubernetes中文社群

1. 理解認證授權 1.1 為什麼要認證 想理解認證，我們得從認證解決什麼問題、防止什麼問題的發生入手。 防止什麼問題呢？是防止有人入侵你的叢集，root你的機器後讓我們叢集依然安全嗎？不是吧，root都到手了，那就為所欲為，防不勝防了。 其實網路安全本身就是為了解決在某些假設成立的條件下如何

使用CoreDNS實現Kubernetes基於DNS的服務發現_Kubernetes中文社群

1.Kubernetes基於DNS的服務發現 在Kubernetes叢集推薦使用Service Name作為服務的訪問地址，因此需要一個Kubernetes叢集範圍的DNS服務實現從Service Name到Cluster Ip的解析，這就是Kubernetes基於DNS的服務發現功能。 在從

數人云架構師：微服務體系中的K8S&Mesos排程與服務發現_Kubernetes中文社群

9月10日在K8S GeekGathering Meetup上，數人云架構師保珠做了關於《K8S&mesos之我見》的主題分享，分別介紹了Kubernetes和Mesos對微服務的支撐，以下是本次分享的實錄—— 本次主要分享主要有以下五個方面： – 容器的價值 – 微服務體系建設 –

Building Microservice NO.1 深圳：Cloud Native架構下的K8S和微服務實踐_Kubernetes中文社群

發展變革，容器化的興起，帶來應用開發部署的變革，也帶來應用設計架構和運維部署變化； 敏捷為王，造就Cloud Native技術及文化大勢已成，雲原生不僅是技術，在技術之上更是一種團隊技術文化； 疾如雷電，持續交付、DevOps、微服務，成為企業在軟體成果對抗當中勝出的有力武器； 突出重圍，K

Kubernetes 的安全機制 APIServer 認證、授權、准入控制_Kubernetes中文社群

本文講解 kubernetes 的安全機制。主要會按照這幾個部分來講解：APIServer 認證、授權、准入控制等。 我們都知道 kubenetes 預設在兩個埠提供服務：一個是基於 https 安全埠 6443，另一個是基於 http 的非安全埠 8080。其中非安全埠 8080 限制只能本

配置Pod的liveness和readiness探針_Kubernetes中文社群

當你使用kuberentes的時候，有沒有遇到過Pod在啟動後一會就掛掉然後又重新啟動這樣的惡性迴圈？你有沒有想過kubernetes是如何檢測pod是否還存活？雖然容器已經啟動，但是kubernetes如何知道容器的程序是否準備好對外提供服務了呢？讓我們通過kuberentes官網的這篇文章

【詳解】以銀行零售業務為例，一個案例說清楚視覺化微服務架構_Kubernetes中文社群

Part 1: API設計和策略 軟體系統的複雜性是一個很痛苦的問題，而且無法避免。Fred Brooks將複雜性描述為，軟體系統解決業務問題所固有的本質複雜性，以及實施該解決方案所帶來的偶發複雜性。 隨著與採用“API優先”工程實踐和微服務架構的組織進行更密切的合作，我發現這種描述越來

91APP新零售平臺實踐分享：靠Kubernetes實現IT微服務架構_Kubernetes中文社群

儘管多數是.NET系統，91APP也積極擁抱輕量級容器技術，通過“鄉村包圍城市”的策略，新興系統先擁抱容器，下一步想轉型更高彈性的微服務架構，關鍵就是匯入Kubernetes來管理複雜的容器叢集 臺灣知名的新零售平臺供貨商91APP，已有超過1萬家品牌企業，通過91APP平臺經營電商生意。為了

第五部分：DogFood環境，Ingress和Edge路由_Kubernetes中文社群

概述 在這篇文章中，我們將向您展示如何使用Linkerd實現的Service Mesh來處理Kubernetes上的入口流量，在Service Mesh中的每個例項上分發流量。我們還將通過一個完整的例子來介紹Linkerd的高階路由功能：如何將特定的請求路由到較新版本的應用例項上，比如用於內部

詳解 Kubernetes 的穩定性和可用性_Kubernetes中文社群

作者/講師：楊朝樂/才雲科技軟體工程師 才雲基礎設施部分運維開發工程師，專注於 Kubernetes 部署及運維。 來源：K8sMeetup 大家好，我叫楊朝樂，來自才雲科技基礎設施部門。今天給大家分享一個平時可能接觸得較少的話題：關於 Kubernetes 的穩定性和可用性。 下面是今天分享

微軟推Jenkins版的Azure容器服務外掛，加速k8s及Azure容器服務部署_Kubernetes中文社群

近日微軟推出Jenkins版本的Azure容器服務（ACS）外掛，微軟資深專案經理Pui Chee Chan表示，無論使用者想選擇何種型別的排程工具，如Docker Swarm、Kubernetes、DC/OS，都能使用Jenkins完成持續部署的工作。 Pui Chee Chan表示，微軟在

如何在Kubernetes（k8s）中暴露服務訪問_Kubernetes中文社群

本文是10月18日Rancher在北京舉辦的Kubernetes技術沙龍中的分享話題之一，由講師張智博整理撰寫成文稿。 Kubernetes概述 最近的一年，kubernetes的發展如此閃耀，正被越來越多的公司採納用於生產環境的實踐。同時，我們可以在最著名的開發者問答社群StackOverf

阿里雲 Serverless Kubernetes 服務上線_Kubernetes中文社群

根據雲原生基金會（CNCF）近日釋出的調查報告，中國公有云市場阿里雲佔據55％市佔率，穩坐國內龍頭。而在國內擁有高人氣的阿里雲，繼去年11月，宣佈要進軍Kubernetes服務之後，近日又再加碼新推服務，釋出了無伺服器Kubernetes叢集服務。 阿里雲所提供的Kubernetes服務，共有

Istio，Kubernetes 的微服務支援_Kubernetes中文社群

簡介 Istio 是一個由 IBM、Google 以及 Lyft 聯合推出的開源軟體，以無痛方式為執行在 Kubernetes 上的微服務提供流量管理，訪問策略管理以及監控等功能。這一軟體目前僅在 Kubernetes 上執行，今後可能會擴充套件到其他平臺。本文會結合官方例子，完成安裝和基礎的

伸縮Kubernetes到2500個節點中遇到的問題和解決方法_Kubernetes中文社群

本片文章即分享Open API在kubernetes 5000之路上的經驗，包括遇到的問題、嘗試解決問題以及找到真正的問題。 遇到的問題以及如何解決 問題一：1 ~ 500個節點之後 問題： kubectl 有時會出現 timeout（p.s. kubectl -v=6 可以顯示所有API細節指令） 嘗試解

7大維度看國外企業為啥選擇gRPC打造高效能微服務？_Kubernetes中文社群

Bugsnag（注：一家雲端bug監控服務商）每天處理數以億計的錯誤資訊，為了處理這些資料，考慮優先構建一個可擴充套件，效能強大的後端系統，並從中學到很多有挑戰性的技術。最近，我們推出了新版本的儀表板，這個專案要求擴充套件系統，來處理服務呼叫的顯著增加，這些呼叫是跟蹤使用者釋出和會話所需的。

Google與思科合作推廣混合雲架構,支援Kubernetes;Azure容器服務ACS改名AKS，以K8S服務為主_Kubernetes中文社群

日前Google和思科合作，加強企業混合雲，讓思科私有云環境得以介接Google公有云環境。 隨著企業需求走向公、私雲混合，這類的合作也越來越多，例如，AWS和Google也分別和VMware合作，以提供企業混合雲服務。而紅帽則是與AWS、Azure及GCP合作，讓OpenShift能在跨雲、

Kubernetes(k8s)1.5新特性:Kubelet API增加認證和授權能力_Kubernetes中文社群

一、背景介紹 在Kubernetes1.5中，對於kubelet新增加了幾個同認證/授權相關的幾個啟動引數，分別是： 認證相關引數： •       anonymous-auth引數：是否啟用匿名訪問，可以選擇true或者false，預設是true，表示啟用匿名訪問。 •       auth

《Spring Cloud Netflix》-- 服務註冊和服務發現-Eureka的服務認證和集群

cluster word self. app server 同步 not eat wal 一、 Eureka的服務認證 1、 服務端添加依賴 <dependency> <groupId>org.springframework.boot&

DaoCloud 雲集 CKA 認證工程師，成為 CNCF 認證 Kubernetes 服務提供商_Kubernetes中文社群

DaoCloud 成為 CNCF 認證 Kubernetes 服務提供商（KCSP），核心產品 DaoCloud Enterprise 2.10 正式起航，全面擁抱 Kubernetes 技術生態，企業級平臺服務能力全方位升級。 憑藉 DaoCloud 深耕雲原生生態的技術實力和豐富經驗，已雲