k8s

https://kubernetes.io/docs/tutorials/kubernetes-basics/

Kubernetes集羣包含有節點代理kubelet和Master組件(APIs, scheduler, etc)，一切都基於分佈式的存儲系統

總體結構

 

開發者開發一個應用後，打包Docker鏡像，上傳到Docker registry；而後編寫一個yaml部署描述文件。開發者經過kubectl（或其它應用），將部署描述文件提交到API server，API server將部署需求更新到etcd。etcd在K8s管理結點中的做用至關於數據庫，其它組件提交到API server的數據都存儲於etcd。API server很是輕量，並不會直接去建立或管理Pod等資源，在多數場景下甚至不會去主動調用其它的K8s組件發出指令。其它組件經過創建和API server的長鏈接，監視關心的對象，監視到變化後，執行所負責的操做。如圖所示，Controller Manager中的控制器監視到新的部署描述後，根據部署描述，建立ReplicaSet、Pod等資源。Scheduler監視到新的Pod資源後，結合集羣的資源狀況，選定一或多個工做結點運行Pod。工做結點上的Kubelet監視到有Pod被計劃在本身的結點後，向Docker等Container runtime發出啓動容器的指令，Docker engineer將按照指令從Docker registy拉取鏡像，而後啓動並運行容器

如下是摘自 凌風探梅的總結

.什麼是kubernetes

　　首先，他是一個全新的基於容器技術的分佈式架構領先方案。Kubernetes(k8s)是Google開源的容器集羣管理系統（谷歌內部:Borg）。在Docker技術的基礎上，爲容器化的應用提供部署運行、資源調度、服務發現和動態伸縮等一系列完整功能，提升了大規模容器集羣管理的便捷性。

　　Kubernetes是一個完備的分佈式系統支撐平臺，具備完備的集羣管理能力，多擴多層次的安全防禦和准入機制、多租戶應用支撐能力、透明的服務註冊和發現機制、內建智能負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和在線擴容能力、可擴展的資源自動調度機制以及多粒度的資源配額管理能力。同時Kubernetes提供完善的管理工具，涵蓋了包括開發、部署測試、運維監控在內的各個環節。

Kubernetes中，Service是分佈式集羣架構的核心，一個Service對象擁有以下關鍵特徵：

• 擁有一個惟一指定的名字
• 擁有一個虛擬IP（Cluster IP、Service IP、或VIP）和端口號
• 可以體統某種遠程服務能力
• 被映射到了提供這種服務能力的一組容器應用上

　　Service的服務進程目前都是基於Socket通訊方式對外提供服務，好比Redis、Memcache、MySQL、Web Server，或者是實現了某個具體業務的一個特定的TCP Server進程，雖然一個Service一般由多個相關的服務進程來提供服務，每一個服務進程都有一個獨立的Endpoint（IP+Port）訪問點，但Kubernetes可以讓咱們經過服務鏈接到指定的Service上。有了Kubernetes內奸的透明負載均衡和故障恢復機制，無論後端有多少服務進程，也無論某個服務進程是否會因爲發生故障而從新部署到其餘機器，都不會影響咱們隊服務的正常調用，更重要的是這個Service自己一旦建立就不會發生變化，意味着在Kubernetes集羣中，咱們不用爲了服務的IP地址的變化問題而頭疼了。

　　容器提供了強大的隔離功能，全部有必要把爲Service提供服務的這組進程放入容器中進行隔離。爲此，Kubernetes設計了Pod對象，將每一個服務進程包裝到相對應的Pod中，使其成爲Pod中運行的一個容器。爲了創建Service與Pod間的關聯管理，Kubernetes給每一個Pod貼上一個標籤Label，好比運行MySQL的Pod貼上name=mysql標籤，給運行PHP的Pod貼上name=php標籤，而後給相應的Service定義標籤選擇器Label Selector，這樣就能巧妙的解決了Service於Pod的關聯問題。

　　在集羣管理方面，Kubernetes將集羣中的機器劃分爲一個Master節點和一羣工做節點Node，其中，在Master節點運行着集羣管理相關的一組進程kube-apiserver、kube-controller-manager和kube-scheduler，這些進程實現了整個集羣的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理能力，而且都是全自動完成的。Node做爲集羣中的工做節點，運行真正的應用程序，在Node上Kubernetes管理的最小運行單元是Pod。Node上運行着Kubernetes的kubelet、kube-proxy服務進程，這些服務進程負責Pod的建立、啓動、監控、重啓、銷燬以及實現軟件模式的負載均衡器。

　　在Kubernetes集羣中，它解決了傳統IT系統中服務擴容和升級的兩大難題。你只需爲須要擴容的Service關聯的Pod建立一個Replication Controller簡稱（RC），則該Service的擴容及後續的升級等問題將迎刃而解。在一個RC定義文件中包括如下3個關鍵信息。

• 目標Pod的定義
• 目標Pod須要運行的副本數量（Replicas）
• 要監控的目標Pod標籤（Label）

　　在建立好RC後，Kubernetes會經過RC中定義的的Label篩選出對應Pod實例並實時監控其狀態和數量，若是實例數量少於定義的副本數量，則會根據RC中定義的Pod模板來建立一個新的Pod，而後將新Pod調度到合適的Node上啓動運行，知道Pod實例的數量達到預約目標，這個過程徹底是自動化。

　　

　Kubernetes優點:

　　　　- 容器編排

　　　　- 輕量級

　　　　- 開源

　　　　- 彈性伸縮

　　　　- 負載均衡

 

Kubernetes主要由如下幾個核心組件組成：

• etcd保存了整個集羣的狀態；
• apiserver提供了資源操做的惟一入口，並提供認證、受權、訪問控制、API註冊和發現等機制；
• controller manager負責維護集羣的狀態，好比故障檢測、自動擴展、滾動更新等；
• scheduler負責資源的調度，按照預約的調度策略將Pod調度到相應的機器上；
• kubelet負責維護容器的生命週期，同時也負責Volume（CVI）和網絡（CNI）的管理；
• Container runtime負責鏡像管理以及Pod和容器的真正運行（CRI）；
• kube-proxy負責爲Service提供cluster內部的服務發現和負載均衡；

每一個API對象都有3大類屬性：元數據metadata、規範spec和狀態status

pod文件

# yaml格式的pod定義文件完整內容：
apiVersion: v1       #必選，版本號，例如v1
kind: Pod       #必選，Pod
metadata:       #必選，元數據
  name: string       #必選，Pod名稱
  namespace: string    #必選，Pod所屬的命名空間
  labels:      #自定義標籤
    - name: string     #自定義標籤名字
  annotations:       #自定義註釋列表
    - name: string
spec:         #必選，Pod中容器的詳細定義
  containers:      #必選，Pod中容器列表
  - name: string     #必選，容器名稱
    image: string    #必選，容器的鏡像名稱
    imagePullPolicy: [Always | Never | IfNotPresent] #獲取鏡像的策略 Alawys表示下載鏡像 IfnotPresent表示優先使用本地鏡像，不然下載鏡像，Nerver表示僅使用本地鏡像
    command: [string]    #容器的啓動命令列表，如不指定，使用打包時使用的啓動命令
    args: [string]     #容器的啓動命令參數列表
    workingDir: string     #容器的工做目錄
    volumeMounts:    #掛載到容器內部的存儲卷配置
    - name: volumestring     #引用pod定義的共享存儲卷的名稱，需用volumes[]部分定義的的卷名
      mountPath: string    #存儲卷在容器內mount的絕對路徑，應少於512字符
      readOnly: boolean    #是否爲只讀模式
    ports:       #須要暴露的端口庫號列表
    - name: string     #端口號名稱
      containerPort: int   #容器須要監聽的端口號
      hostPort: int    #容器所在主機須要監聽的端口號，默認與Container相同
      protocol: string     #端口協議，支持TCP和UDP，默認TCP
    env:       #容器運行前需設置的環境變量列表
    - name: string     #環境變量名稱
      value: string    #環境變量的值
    resources:       #資源限制和請求的設置
      limits:      #資源限制的設置
        cpu: string    #Cpu的限制，單位爲core數，將用於docker run --cpu-shares參數
        memory: string     #內存限制，單位能夠爲Mib/Gib，將用於docker run --memory參數
      requests:      #資源請求的設置
        cpu: string    #Cpu請求，容器啓動的初始可用數量
        memory: string     #內存清楚，容器啓動的初始可用數量
    livenessProbe:     #對Pod內個容器健康檢查的設置，當探測無響應幾回後將自動重啓該容器，檢查方法有exec、httpGet和tcpSocket，對一個容器只需設置其中一種方法便可
      exec:      #對Pod容器內檢查方式設置爲exec方式
        command: [string]  #exec方式須要制定的命令或腳本
      httpGet:       #對Pod內個容器健康檢查方法設置爲HttpGet，須要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket:     #對Pod內個容器健康檢查方式設置爲tcpSocket方式
         port: number
       initialDelaySeconds: 0  #容器啓動完成後首次探測的時間，單位爲秒
       timeoutSeconds: 0   #對容器健康檢查探測等待響應的超時時間，單位秒，默認1秒
       periodSeconds: 0    #對容器監控檢查的按期探測時間設置，單位秒，默認10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged:false
    restartPolicy: [Always | Never | OnFailure]#Pod的重啓策略，Always表示一旦無論以何種方式終止運行，kubelet都將重啓，OnFailure表示只有Pod以非0退出碼退出才重啓，Nerver表示再也不重啓該Pod
    nodeSelector: obeject  #設置NodeSelector表示將該Pod調度到包含這個label的node上，以key：value的格式指定
    imagePullSecrets:    #Pull鏡像時使用的secret名稱，以key：secretkey格式指定
    - name: string
    hostNetwork:false      #是否使用主機網絡模式，默認爲false，若是設置爲true，表示使用宿主機網絡
    volumes:       #在該pod上定義共享存儲卷列表
    - name: columestring     #共享存儲卷名稱 （volumes類型有不少種）
      emptyDir: {}     #類型爲emtyDir的存儲卷，與Pod同生命週期的一個臨時目錄。爲空值
      hostPath: string     #類型爲hostPath的存儲卷，表示掛載Pod所在宿主機的目錄
        path: string     #Pod所在宿主機的目錄，將被用於同期中mount的目錄
      secret:      #類型爲secret的存儲卷，掛載集羣與定義的secre對象到容器內部
        scretname: string  
        items:     
        - key: string
          path: string
      configMap:     #類型爲configMap的存儲卷，掛載預約義的configMap對象到容器內部
        name: string
        items:
        - key: string
          path: string    

Node

• 每一個Node節點都運行着如下一組關鍵進程
• kubelet：負責對Pod對於的容器的建立、啓停等任務
• kube-proxy：實現Kubernetes Service的通訊與負載均衡機制的重要組件
• Docker Engine（Docker）：Docker引擎，負責本機容器的建立和管理工做

複製控制器（Replication Controller，RC）

Replication Controller用來管理Pod的副本，保證集羣中存在指定數量的Pod副本，是實現彈性伸縮、動態擴容和滾動升級的核心。

隨後能夠經過Label Selector（標籤選擇器）查詢和篩選擁有某些Label的資源對象，Kubernetes經過這種方式實現了相似SQL的簡單又通用的對象查詢機制

 

　Label Selector在Kubernetes中重要使用場景以下:

 

　　1.kube-Controller進程經過資源對象RC上定義Label Selector來篩選要監控的Pod副本的數量，從而實現副本數量始終符合預期設定的全自動控制流程

　　2.kube-proxy進程經過Service的Label Selector來選擇對應的Pod，自動創建起每一個Service島對應Pod的請求轉發路由表，從而實現Service的智能負載均衡

　　3.經過對某些Node定義特定的Label，而且在Pod定義文件中使用Nodeselector這種標籤調度策略，kuber-scheduler進程能夠實現Pod」定向調度「的特性

 

Label

Label是Replication Controller和Service運行的基礎，兩者經過Label來進行關聯Node上運行的Pod。

Service

　Node IP：Node節點的IP地址

　Pod IP： Pod的IP地址

　Cluster IP：Service的IP地址

Service是定義一系列Pod以及訪問這些Pod的策略的一層抽象。Service經過Label找到Pod組

2個後臺Pod，定義後臺Service的名稱爲‘backend-service’，

lable選擇器爲（tier=backend, app=myapp）。backend-service 的Service會完成以下兩件重要的事情：

1.會爲Service建立一個本地集羣的DNS入口，所以前端Pod只須要DNS查找主機名爲 ‘backend-service’，就可以解析出前端應用程序可用的IP地址。

2.如今前端已經獲得了後臺服務的IP地址，可是它應該訪問2個後臺Pod的哪個呢？Service在這2個後臺Pod之間提供透明的負載均衡，會將請求分發給其中的任意一個（以下面的動畫所示）。經過每一個Node上運行的代理（kube-proxy）完成.

Deployment

Deployment爲Pod和Replica Set（下一代Replication Controller）提供聲明式更新,只須要在Deployment中描述你想要的目標狀態是什麼，Deployment controller就會幫你將Pod和Replica Set的實際狀態改變到你的目標狀態

一個典型的用例以下：

• 使用Deployment來建立ReplicaSet。ReplicaSet在後臺建立pod。檢查啓動狀態，看它是成功仍是失敗。
• 而後，經過更新Deployment的PodTemplateSpec字段來聲明Pod的新狀態。這會建立一個新的ReplicaSet，Deployment會按照控制的速率將pod從舊的ReplicaSet移動到新的ReplicaSet中。
• 若是當前狀態不穩定，回滾到以前的Deployment revision。每次回滾都會更新Deployment的revision。
• 擴容Deployment以知足更高的負載。
• 暫停Deployment來應用PodTemplateSpec的多個修復，而後恢復上線。
• 根據Deployment 的狀態判斷上線是否hang住了。
• 清除舊的沒必要要的ReplicaSet。

Ingress

 service和pod的IP僅可在集羣內部訪問。集羣外部的請求須要經過負載均衡轉發到service在Node上暴露的NodePort上，而後再由kube-proxy將其轉發給相關的Pod。而Ingress就是爲進入集羣的請求提供路由規則的集合

Ingress能夠給service提供集羣外部訪問的URL、負載均衡、SSL終止、HTTP路由等。爲了配置這些Ingress規則，集羣管理員須要部署一個Ingress controller，它監聽Ingress和service的變化，並根據規則配置負載均衡並提供訪問入口。

apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test spec: rules: - host: foo.bar.com http: paths: - path: /foo backend: serviceName: s1 servicePort: 80 - path: /bar backend: serviceName: s2 servicePort: 80

Volume

Secrets

 

 echo -n "root" | base64
cm9vdA==

 

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: MWYyZDFlMmU2N2Rm
  username: YWRtaW4=

建立好secret以後，有兩種方式來使用它：

• 以Volume方式
• 以環境變量方式

將Secret掛載到Volume中

apiVersion: v1 kind: Pod metadata: labels: name: db name: db spec: volumes: - name: secrets secret: secretName: mysecret 建立的secrect名字 containers: - image: gcr.io/my_project_id/pg:v1 name: db volumeMounts: - name: secrets mountPath: "/etc/secrets" readOnly: true ports: - name: cp containerPort: 5432 hostPort: 5432

將Secret導出到環境變量中

       env:
        - name: WORDPRESS_DB_USER
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: username
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: password

 

ConfigMap  容器應用的配置管理

ConfigMap能夠經過多種方式在Pod中使用，好比設置環境變量、設置容器命令行參數、在Volume中建立配置文件等。

建立一個配置文件  並將配置引入pod

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-appvars
data:
  key-serverxml:
    <?xml Version='1.0'encoding='utf-8'?>
    <Server port="8005"shutdown="SHUTDOWN">
    .....
      </service>
    </Server>
  key-loggingproperties:
    "handlers=lcatalina.org.apache.juli.FileHandler,
    ...."

    volumeMounts:
    - name: serverxml                          #引用volume名
      mountPath:/configfiles                       #掛載到容器內部目錄
        configMap:
          name: cm-test-appconfigfile                  #使用configmap定義的的cm-appconfigfile
          items:
          - key: key-serverxml                     #將key=key-serverxml
            path: server.xml                           #value將server.xml文件名進行掛載
          - key: key-loggingproperties                 #將key=key-loggingproperties    
            path: logging.properties                   #value將logging.properties文件名進行掛載　

健康檢查的三種方式

ExecAction：在容器內部執行一個命令，若是該命令的返回值爲0，則表示容器健康

TCPSocketAction：經過容器ip地址和端口號執行TCP檢查，若是可以創建tcp鏈接代表容器健康

HTTPGetAction：經過容器Ip地址、端口號及路徑調用http get方法請求資源，若是響應的狀態嗎大於200且小於400，則認爲容器健康

spec:
  containers:
  - name: tomcat
    image: grc.io/google_containers/tomcat
    args:  配置一個命令，健康檢查執行
    -/bin/sh
    - -c
    -echo ok >/tmp.health;sleep10; rm -fr /tmp/health;sleep600
    livenessProbe:
      exec:
        command:
        -cat
        -/tmp/health
      initianDelaySeconds:15
      timeoutSeconds:1　
  
  livenessProbe:
      tcpSocket:
        port: 80
      initianDelaySeconds:30
      timeoutSeconds:1

    livenessProbe:
      httpGet:
        path:/_status/healthz
        port: 80
      initianDelaySeconds:30
      timeoutSeconds:1

initialDelaySeconds：啓動容器後首次監控檢查的等待時間，單位秒
timeouSeconds：健康檢查發送請求後等待響應的超時時間，單位秒。當發生超時就被認爲容器沒法提供服務無，該容器將被重啓

健康檢查

NodeSelector:定向調度

給node打上標籤 kubectl label nodes k8s-node-1 label1=test

nodeSelector:
          label1: test

 

NodeAffinity：親和性調度

該調度策略是未來替換NodeSelector的新一代調度策略。因爲NodeSelector經過Node的Label進行精確匹配，全部NodeAffinity增長了In、NotIn、Exists、DoesNotexist、Gt、Lt等操做符來選擇Node。調度側露更加靈活。

• 日誌收集，好比fluentd，logstash等
• 系統監控，好比Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等
• 系統程序，好比kube-proxy, kube-dns, glusterd, ceph等

kubectl get namespaces
kubectl create namespace new-namespace
kubectl get pods -l label名 -n namespace名
kubectl scale deployment nginx-deployment --replicas 10 擴容
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 更新鏡像部署
kubectl edit deployment/nginx-deployment
kubectl create -f deployment.yaml文件 -n 命名空間
kubectl delete pods pods名稱
kubectl get svc -n 名稱 -o 樣式 | 附加範圍
kubectl delete pods,services -l name=myLabel(標籤) --include-uninitialized(包含還沒有初始化的)
kubectl exec -it pod名 /bin/bash -n 命名空間
kubectl rollout history deployment/deployment名稱 -n --revision=版本號 查看提交歷史
kubectl rollout history deployment/deployment名稱 -n
kubectl rollout undo deployment/deployment名稱 --to-revision=版本號 -n

kubectl rolling-update redis-master --image=redis-master:2.0  升級內部鏡像

kubectl get pods --show-labels kubectl rollout status deployment/nginx-deployment 監控回撤狀態 kubectl describe deployment 部署名 -n 空間 查看詳細 kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi kubectl get deployment pod名 -o yaml -n 查看部署文件 建立環境變量 將常量參數寫入其中 kubectl create configmap env-config --from-literal=log_level=INFO kubectl logs volume-pod -c busybox