Kubernetes Service Account

Service Account 概念的引用是以這樣為基礎的使用場景:執行在Pod裡的處理程序需要呼叫Kubernetes API 以及非Kubernetes API的其他服務. 我們使用Service Account 來為Pod 提供認證.

Service Account 和 User Account 可能會帶來某種程度上的混淆, 它們的區別如下:

User Account 通常是為人類設計的,而Service Account 則是為執行在Pod中的應用設計的
User Account是全域的,即可跨Namespace使用:而Service Account 是限定Namespace的, 即僅在所屬的Namespace下使用
建立一個新的User Account 通常需要較高的特權並且需要經過比較複雜的,而Service Account則不然

Kubernetes API Server 目前支援Authentication和 Authorization機制進行安全存取控制

Authentication:
  1. Basic Authentication
              vim  basic_auth.csv
                  admin_passwd,admin,1
                  test_passwd,test,2

          然後設定Kubernetes API Server 的啟動參數
           --basic-auth-file=/path/to/basic_auth.csv

  1. Token Authentication 
              vim token_auth.csv
                  kefjeeojjojepfeof3jojo2oj,admin,1
                  kmckemkekcekmekcmk,test,2

          其中 Token 是任意字串,可以用以下指令產生
           $ echo $(cat /dev/urandom | base64 | tr -d "=+/" | dd bs=32 count=12>/dev/null
          然後設定Kubernetes API Server 的啟動參數
            —token-auth-file=/path/to/token_auth.csv

  1. Client Certificate Authentication     
                 --client-ca-file=/path/to/ca.crt

  1. OpenID Authentication     
               --oidc-issuer-url=<url>
               --oidc-client-id=<id_token>

      5.  Keystone Authentication
                --experimental-keystone-url=<AuthURL>



Service Account 在API Server啟動參數
--service-account-key-file=" "

Service Account 在Controller Manager啟動參數
--service-account-private-key-file=" "
--root-ca-file=" "

使用預設 Service Account
Kubernetes Controller Manager 會為每個Namespace 預設建立一個Service Account 我們稱為預設Service Account

$ kubectl get serviceaccount

預設Service Account 包含一個Secret:

$ kubectl describe serviceaccount default

查詢該Secret:

$ kubectl describe secret default-token-lm2tq
查詢顯示這是一個Kubernetes.io/service-account-token 類型的secret, 稱為 Service Account Secret , 包含兩個資料token 和 ca.crt 這也是由kubernetes controller manager 產生的. 其中token是由 --service-account-private-key-file指定的金鑰簽發產生的,而ca.crt是由--root-ca-file指定的CA憑證.

這樣一來, 新增的Pod如果沒有指定Service Account, 就會使用預設Service Account, 掛載Service Account 到容器目錄中 /var/run/secrets/kubernetes.io/serviceaccount
$ kubectl exec my-pod -- ls /var/run/secrets/kubernetes.io/serviceaccount/
$ kubectl exec my-pod -- cat  /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
$ kubectl exec my-pod -- cat  /var/run/secrets/kubernetes.io/serviceaccount/token

Pod中的應用透過token和ca.crt 存取kubernetes API Server, 同時kubernetes 提供非常方便的方式讓Pod取得kubernetes API Server 的位址.

Kubernetes 在初始化的時候會建立一個Kubernetes Service , 叫作kubernetes, 它代表的就是kubernetes API Server

$ kubectl describe service kubernetes

kubernetes service的虛擬IP是10.254.0.1, 這是kubernetes API Server設定的Service 網段的第一個IP (--service-cluster-ip-range=10.254.0.0/16) 然後將轉發HTTPS的443通訊埠到192.168.3.146:6443, 即Kubernetes API Server的地址和HTTPS安全通訊埠, 並且Kubernetes Service 是最早建立的,新增的Pod中可以透過環境變數取得來存取Kubernetes API Server(也可以透過DNS方式),Pod中的處理程序就可以存取Kubernetes API Server, 我們現在簡單實現一個指令搞 curl-k8s-api.sh 來呼叫 Kubernetes API;

#!/bin/sh

Endpoint=$1
ServiceAccountToken=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
ServiceAccountRootCA=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
KubernetesserverURL="http://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_POST"

curl -XGET -H "Authorization: Bearer $ServiceAccountToken" \
--caret $ServiceAccountRootCA \
${KubernetesserverURL}${Endpoint}

我們需要將指令稿curl-k8s.api.sh 放入Pod 容器中, 然後存取/api 版本資訊
$ kubectl exec -it my-pod /bin/bash
    vim curl-k8s.api.sh

$ kubectl exec my-pod -- cat curl-k8s.api.sh
$ kubectl exec my-pod -- curl-k8s.api.sh /api
  {
     "version":{
       "v1"
    }
 }


建立自訂Service Account
使用者可以建立自訂的Service Account
vim serviceaccount.yaml
 
apiVersion: v1
kind: ServiceAccount
metadata:
     name: my-serviceaccount


$ kubectl create -f serviceaccount.yaml
$ kubectl describe serviceaccount my-serviceaccount

透過定義檔案建立Service Account Secret:
vim serviceaccountSecret.yaml

apiVersion: v1
kind: secret
metadata:
     name: my-serviceaccount-secret
     annotations:
         kubernetes.io/service-account.name: my-serviceaccount
type: kubernetes.io/service-account-token

$ kubectl create -f serviceaccountSecret.yaml

$ kubectl path serviceaccount my-serviceaccount -p '{"secrets": [{"name": "my-serviceaccount-secret"}]}’

然後刪除自動建立的Service Account Secret
$ kubectl delete secret my-serviceaccount-token-ivsml

在Pod 的定義中可以透過.spec.serviceAccountName 指定Service Account 

apiVersion: v1
kind: Pod
metadata:
     name: busy box
     namespace: default
spec:
   containers:
   -name: busybox
    image:busybox
    command:
      -"sleep"
      -"3600"
   restartPolicy: Always
   serviceAccountName: my-serviceaccount


留言

張貼留言

這個網誌中的熱門文章

Json概述以及python對json的相關操作

圖片
什麼是json： JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。它基於JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一個子集。JSON採用完全獨立於語言的文本格式，但是也使用了類似於C語言家族的習慣（包括C, C++, C#, Java, JavaScript, Perl, Python等）。這些特性使JSON成為理想的數據交換語言。 JSON建構於兩種結構： “名稱/值”對的集合（A collection of name/value pairs）。不同的語言中，它被理解為對象（object），紀錄（record），結構（struct），字典（dictionary），哈希表（hash table），有鍵列表（keyed list），或者關聯數組（associative array）。 值的有序列表（An ordered list of values）。在大部分語言中，它被理解為數組（array）。 這些都是常見的數據結構。事實上大部分現代計算機語言都以某種形式支持它們。這使得一種數據格式在同樣基於這些結構的編程語言之間交換成為可能。 jso官方說 ​​明參見：http://json.org/ Python操作json的標準api庫參考：http://docs.python.org/library/json.html 對簡單數據類型的encoding 和decoding： 使用簡單的json.dumps方法對簡單數據類型進行編碼，例如： import json obj = [[ 1 , 2 , 3 ], 123 , 123.123 , 'abc' ,{ 'key1' :( 1 , 2 , 3 ), 'key2' :( 4 , 5 , 6 )}] encodedjson = json.dumps(obj) print repr (obj) print encodedjson 輸出： [[1, 2, 3], 123, 123.123, 'abc', {'ke...
閱讀完整內容

Docker容器日誌查看與清理

1. 問題 docker容器日誌導致主機磁盤空間滿了。 docker logs -f container_name 劈裡啪啦一大堆，很佔用空間，不用的日誌可以清理掉了。  2. 解決方法 2.1 找出Docker容器日誌 在linux上，容器日誌一般存放在 /var/lib/docker/containers/container_id/ 下面，查看各個日誌文件大小的腳本docker_log_size.sh，內容如下： #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do ls -lh $log done # chmod +x docker_log_size.sh # ./docker_log_size.sh 2.2 清理Docker容器日誌（治標） 如果docker容器正在運行，那麼使用 rm -rf 方式刪除日誌後，通過 df -h 會發現磁盤空間並沒有釋放。 原因是在Linux或者Unix系統中，通過 rm -rf 或者文件管理器刪除文件，將會從文件系統的目錄結構上解除鏈接（unlink）。 如果文件是被打開的（有一個進程正在使用），那麼進程將仍然可以讀取該文件，磁盤空間也一直被佔用。 正確姿勢是 cat /dev/null > *-json.log ，當然你也可以通過 rm -rf 刪除後重啟docker。 接下來，提供一個日誌清理腳本 clean_docker_log.sh ，內容如下： #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs d...
閱讀完整內容

利用 Keepalived 提供 VIP

Keepalived 是一種基於 VRRP 協定實現的高可靠 Web 服務方案，用於防止單點故障問題。因此一個 Web 服務運作至少會擁有兩台伺服器執行 Keepalived，一台作為 master，一台作為 backup，並提供一個虛擬 IP（VIP），master 會定期發送特定訊息給 backup 伺服器，當 backup 沒收到 master 訊息時，表示 master 已故障，這時候 backup 會接管 VIP，繼續提供服務，來確保服務的高可靠性。 VRRP VRRP（Virtual Router Redundancy Protocol，虛擬路由器備援協定），是一個提供備援路由器來解決單點故障問題的協定，該協定有兩個重要概念： * VRRP 路由器與虛擬路由器：VRRP 路由器是表示運作 VRRP 的路由器，是一個實體裝置，而虛擬路由器是指由 VRRP 建立的邏輯路由器。一組 VRRP 路由器協同運作，並一起構成一台虛擬路由器，該虛擬路由對外提供一個唯一固定的 IP 與 MAC 位址的邏輯路由器。 * 主控制路由器（master）與備援路由器（backup）：主要是在一組 VRRP 中的兩種互斥角色。一個 VRRP 群組中只能擁有一台是 master，但可以有多個 backup 路由器。 VRRP 協定使用選擇策略從路由器群組挑選一台作為 master 來負責 ARP 與轉送 IP 封包，群組中其他路由器則作為 backup 的角色處理等待狀態。當由於某種原因造成 master 故障時，backup 會在幾秒內成為 master 繼續提供服務，該階段不用改變任何 IP 與 MAC 位址。 Keepalived 節點配置 IP ADDRESS ROLE 172.16.1.101 vip 172.16.1.102 master 172.16.1.103 backup 安裝與設定 這 ubuntu 14.04 LTS Server 中已經內建了 Keepalived 可以透過 apt-get 來安裝： $ sudo apt-get install -y keepalived 也可以透過 source code 進行安裝，流程如下： $ sudo apt-get install build-essential libssl-dev $ wge...
閱讀完整內容