k8s簡述

時間 2019-11-17

標籤 k8s 簡述简体版

原文原文鏈接

openstack用於管理虛擬機（計算、存儲、管理），K8S用於管理容器，二者自己無聯繫，但能夠把openstack管理的虛擬機當作容器，採用K8S管理。html

K8s是kubernetes的縮寫，8替換了中間的8個字母「ubernete」。java

Kubernetes是一個跨主機集羣的開源的容器調度平臺，它能夠自動化應用容器的部署、擴展和操做，提供以容器爲中心的基礎架構。k8s的目標是構建一個軟件和工具的生態系統，以減輕在公有云或私有云上運行應用程序的負擔。node

Kubernetes 項目由 Google 公司在 2014 年啓動。Kubernetes 創建在 Google 公司超過十餘年的運維經驗基礎之上，Google 全部的應用都運行在容器上, 再與社區中最好的想法和實踐相結合，也許它是最受歡迎的容器平臺。mysql

Kubernetes 能夠在物理或虛擬機集羣上調度和運行應用程序容器。然而，Kubernetes 還容許開發人員從物理和虛擬機’脫離’，從以主機爲中心的基礎架構轉移到以容器爲中心的基礎架構，這樣能夠提供容器固有的所有優勢和益處。Kubernetes 提供了基礎設施來構建一個真正以容器爲中心的開發環境。nginx

一． Kubernetes架構

Kubernetes包含三類組件（components）：master components、node components和addons。其中addons是插件，提供具體的功能和服務。master組件能夠在集羣中的任何節點上運行，然而爲了簡單起見，設置腳本一般會將全部master組件運行在同一個虛擬機上，而且不用在此虛擬機上運行用戶容器。運行master組件的節點便被獨立出來，稱爲Master節點，集羣的其他節點稱爲工做節點Node。git

1.1 Master組件

Kubernetes將集羣中的機器劃分爲一個Master節點和一羣工做節點（Node）。其中，Master節點上運行着集羣管理相關的一組進程：etcd、kube-apiserver、kube-controller-manager、kube-scheduler、cloud-controller-manager，後四個組件構成了Kubernetes的總控中心，這些進程實現了整個集羣的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理功能，而且全都是自動完成。github

etcd web

用於持久化存儲集羣中全部的資源對象，如Node、Service、Pod、RC、Namespace等；API Server提供了操做etcd的封裝接口API，這些API基本上都是集羣中資源對象的增刪改查及監聽資源變化的接口。sql

kube-apiserverdocker

提供了資源對象的惟一操做入口，其餘全部組件都必須經過它提供的API來操做資源數據，經過對相關的資源數據「全量查詢」+「變化監聽」，這些組件能夠很「實時」地完成相關的業務功能。

1）提供了集羣管理的REST API接口(包括認證受權、數據校驗以及集羣狀態變動)；

2）提供其餘模塊之間的數據交互和通訊的樞紐（其餘模塊經過API Server查詢或修改數據，只有API Server才直接操做etcd）;

3）資源配額控制的入口；

4）擁有完備的集羣安全機制。

kube-controller-manager

集羣內部的管理控制中心，其主要目的是實現Kubernetes集羣的故障檢測和恢復的自動化工做，好比根據RC的定義完成Pod的複製或移除，以確保Pod實例數符合RC副本的定義；根據Service與Pod的管理關係，完成服務的Endpoints對象的建立和更新；其餘諸如Node的發現、管理和狀態監控、死亡容器所佔磁盤空間及本地緩存的鏡像文件的清理等工做也是由Controller Manager完成的。

kube-scheduler

集羣中的調度器，負責Pod在集羣節點中的調度分配。

cloud-controller-manager

爲底層雲服務提供商提供支持，從v1.6引進，原來版本中k8s code依賴雲服務提供商代碼，被集成在kube-controller-manager中。本質就是循環調用cloud-provider-specific controllers，可經過啓動kube-controller-manager時設置--cloud-provider爲external關閉此特性。

1.2 Node組件

在每一個Node上運行kubelet、kube-proxy、Container Runtime三個組件，負責對本節點上的Pod的生命週期進行管理，以及實現服務代理的功能。

Kubelet

負責本Node節點上的Pod的建立、修改、監控、刪除等全生命週期管理，同時Kubelet定時「上報」本Node的狀態信息到API Server裏。注意kubelet無論理非k8s建立的容器。

Proxy

實現了Service的代理與軟件模式的負載均衡器。

container Runtime

運行containers，k8s支持容器：Docker、containerd、cri-o、rktlet等實現k8s container Runtime Interface接口的容器。

1.3 Addons組件

Addons是pods和services，實現cluster特性。經常使用的插件有：DNS（每一個clusters都應該有一個cluster DNS），Web UI（dashboard），Container Resource Monitoring，Cluster-level logging等等。

1.4 流程

經過Kubectl提交一個建立RC的請求，該請求經過API Server被寫入etcd中，此時Controller Manager經過API Server的監聽資源變化的接口監聽到這個RC事件，分析以後，發現當前集羣中尚未它所對應的Pod實例，因而根據RC裏的Pod模板定義生成一個Pod對象，經過API Server寫入etcd，接下來，此事件被Scheduler發現，它當即執行一個複雜的調度流程，爲這個新Pod選定一個落戶的Node，而後經過API Server將這一結果寫入到etcd中，隨後，目標Node上運行的Kubelet進程經過API Server監測到這個「新生的」Pod，並按照它的定義，啓動該Pod並不辭辛苦地負責它的下半生，直到Pod的生命結束。

隨後，咱們經過Kubectl提交一個新的映射到該Pod的Service的建立請求，Controller Manager會經過Label標籤查詢到相關聯的Pod實例，而後生成Service的Endpoints信息，並經過API Server寫入到etcd中，接下來，全部Node上運行的Proxy進程經過API Server查詢並監聽Service對象與其對應的Endpoints信息，創建一個軟件方式的負載均衡器來實現Service訪問到後端Pod的流量轉發功能。

客戶端經過Kubectl命令行工具或Kubectl Proxy來訪問Kubernetes系統，在Kubernetes集羣內部的客戶端能夠直接使用Kubectl命令管理集羣。Kubectl Proxy是API Server的一個反向代理，在Kubernetes集羣外部的客戶端能夠經過Kubernetes Proxy來訪問API Server。

二．核心概念

2.1 Node

Node做爲集羣中的工做節點，運行真正的應用程序，在Node上Kubernetes管理的最小運行單元是Pod。Node上運行着Kubernetes的Kubelet、kube-proxy服務進程，這些服務進程負責Pod的建立、啓動、監控、重啓、銷燬、以及實現軟件模式的負載均衡。

Node包含的信息：

Node地址：主機的IP地址，或Node ID。
Node的運行狀態：Pending、Running、Terminated三種狀態。
Node Condition：…
Node系統容量：描述Node可用的系統資源，包括CPU、內存、最大可調度Pod數量等。
其餘：內核版本號、Kubernetes版本等。

查看Node信息：

kubectl describe node

2.2 objects

Kubernetes Objects are persistent entities in the Kubernetes system. Kubernetes用entities表徵cluster狀態。特別地，objects能描述：

What containerized applications are running (and on which nodes)
The resources available to those applications
The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance

k8s對象是一條內容記錄，一旦建立了對象，k8s會持續工做確保對象存在。能夠經過Kubernetes API或kubectl命令行建立對象。

每一個 Kubernetes 對象包含兩個嵌套的對象字段，它們負責管理對象的配置：對象 spec 和對象 status 。spec 是必需的，它描述了對象的 指望狀態（Desired State） —— 但願對象所具備的特徵。 status 描述了對象的 實際狀態（Actual State），它是由 Kubernetes 系統提供和更新的。在任什麼時候刻，Kubernetes 控制面一直努力地管理着對象的實際狀態以與指望狀態相匹配。

.yaml文件用來描述k8s對象，傳參給kubectl後，kubectl發起API請求將信息轉換爲JSON格式。一個.yaml示例：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record

輸出相似以下這樣：

deployment "nginx-deployment" created

Kubernetes API Reference提供了全部可用對象的spec格式。可經過命令kubectl api-resources獲取k8s支持的全部object。

2.3 Pod

Pod是一個邏輯概念，它是Kubernetes資源調度的單元，通常會把一組功能強相關的容器邏輯上稱之爲一個pod，Pod就是所說的實例。做爲一個邏輯概念，pod自己沒有資源，pod中的容器具備資源，建立pod，能夠經過定義pod模塊。

Pod包含一個或多個緊密相關的容器，一個Pod能夠被一個容器化的環境看做應用層的「邏輯宿主機」；一個Pod中的多個容器應用一般是緊密耦合的，Pod在Node上被建立、啓動或者銷燬；每一個Pod裏運行着一個特殊的被稱之爲Pause的容器，其餘容器則爲業務容器，這些業務容器共享Pause容器的網絡棧和Volume掛載卷，所以他們之間通訊和數據交換更爲高效，在設計時咱們能夠充分利用這一特性將一組密切相關的服務進程放入同一個Pod中。

Pod裏的多個業務容器共享Pause容器的IP，稱爲PodIP，同一個Pod裏的容器之間僅需經過localhost就能互相通訊。K8s要求底層網絡支持集羣中任意兩個Pod之間的TCP/IP直接通訊，這一般採用虛擬二層網絡技術來實現，如Flannel、Openvswitch等，所以須要牢記：在k8s裏，一個Pod裏的容器與另外主機上的Pod容器可以直接通訊。

一個Pod中的應用容器共享同一組資源：

PID命名空間：Pod中的不一樣應用程序能夠看到其餘應用程序的進程ID；
網絡命名空間：Pod中的多個容器可以訪問同一個IP和端口範圍；
IPC命名空間：Pod中的多個容器可以使用SystemV IPC或POSIX消息隊列進行通訊；
UTS命名空間：Pod中的多個容器共享一個主機名；
Volumes（共享存儲卷）：Pod中的各個容器能夠訪問在Pod級別定義的Volumes；

Pod的生命週期經過Replication Controller來管理；經過模板進行定義，而後分配到一個Node上運行，在Pod所包含容器運行結束後，Pod結束。

Kubernetes爲Pod設計了一套獨特的網絡配置，包括：爲每一個Pod分配一個IP地址，使用Pod名做爲容器間通訊的主機名等。

缺點: 不支持高併發, 高可用, 當Pod當機後沒法自動恢復。

2.4 RC（Replication Controller）

ReplicationController（簡稱rc）是pod的複製抽象，用於解決pod的擴容縮容問題。一般，分佈式應用爲了性能或高可用性的考慮，須要複製多份資源，而且根據負載狀況動態伸縮。經過replicationController，咱們能夠指定一個應用須要幾份複製，Kubernetes將爲每份複製建立一個pod，而且保證明際運行pod數量老是與該複製數量相等(例如，當前某個pod宕機時，自動建立新的pod來替換)。

RC中selector設置一個label，去關聯pod的label，selector的label與pod的label相同，那麼該pod就是該rc的一個實例；RC中Replicas設置副本數大小，系統根據該值維護pod的副本數。

Replicaset在繼承Pod的全部特性的同時, 它能夠利用預先建立好的模板定義副本數量並自動控制, 經過改變Pod副本數量實現Pod的擴容和縮容。

2.5 Service

在Kubernetes的世界裏，雖然每一個Pod都會被分配一個單獨的IP地址，但這個IP地址會隨着Pod的銷燬而消失，這就引出一個問題：若是有一組Pod組成一個集羣來提供服務，那麼如何來訪問它呢？Service！

service是pod的路由代理抽象，用於解決pod之間的服務發現問題，即上下游pod之間使用的問題。傳統部署方式中，實例所在的主機ip（或者dns名字）通常是不會改變的，可是pod的運行狀態可動態變化(好比容器重啓、切換機器了、縮容過程當中被終止了等)，因此訪問端不能以寫死IP的方式去訪問該pod提供的服務。service的引入旨在保證pod的動態變化對訪問端透明，訪問端只須要知道service的地址，由service來提供代理。

一個Service能夠看做一組提供相同服務的Pod的對外訪問接口，Service做用於哪些Pod是經過Label Selector來定義的。

擁有一個指定的名字（好比my-mysql-server）；
擁有一個虛擬IP（Cluster IP、Service IP或VIP）和端口號，銷燬以前不會改變，只能內網訪問；
可以提供某種遠程服務能力；
被映射到了提供這種服務能力的一組容器應用上；

若是Service要提供外網服務，需指定公共IP和NodePort，或外部負載均衡器。

NodePort

系統會在Kubernetes集羣中的每一個Node上打開一個主機的真實端口，這樣，可以訪問Node的客戶端就能經過這個端口訪問到內部的Service了。

Kubernetes默認對外的NodePort限制範圍爲30000-32767, 這裏若是要使用一些經常使用的端口(80，8080， 443)需將這個範圍放大。

# vi /etc/kubernetes/manifests/kube-apiserver.yaml

在--service-cluster-ip-range與insecure-port間添加以下node port配置

- --service-cluster-ip-range=10.96.0.0/12
- --service-node-port-range=0-32767
- --insecure-port=0

EndPoint

Endpoint是可被訪問的服務端點，即一個狀態爲running的pod，它是service訪問的落點，只有service關聯的pod纔可能成爲endpoint。

一個service示例：

apiVersion: v1
kind: Service
metadata:
  name: demo
spec:
  type: NodePort
  ports:
    - port: 80
      nodePort: 80
  selector:
    app: httpd-demo

Tip: 若是要對某一Pod或deployment添加對外訪問端口, 這裏service添加的selector的鍵值需與之相對應。

2.6 Deployment

Deployment在繼承Pod和Replicaset的全部特性的同時, 它能夠實現對template模板進行實時滾動更新並具有咱們線上的Application life circle的特性。

使用kubectl edit -f deployment.yaml和kubectl apply -f deployment.yaml能夠實時編輯配置從而達到擴容或縮容的效果。

2.7 Volume

Volume是Pod中可以被多個容器訪問的共享目錄。

2.8 Label

Label以key/value的形式附加到各類對象上，如Pod、Service、RC、Node等，以識別這些對象，管理關聯關係等，如Service和Pod的關聯關係。

三. kubectl命令行工具

3.1 kubectl

kubectl是Kubernetes集羣的命令行工具，經過kubectl可以對集羣自己進行管理，並可以在集羣上進行容器化應用的安裝部署。

kubectl [command] [TYPE] [NAME] [flags] [options]
Use "kubectl <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all commands).

command：指定要對資源執行的操做，如create、get、describe和delete等。

Basic Commands (Beginner):
  create         Create a resource from a file or from stdin.
  expose    使用replication controller, service, deployment或者pod並暴露它做爲一個新的k8s Service
  run            在集羣中運行一個指定的鏡像
  set            爲 objects 設置一個指定的特徵
 
Basic Commands (Intermediate):
  explain        查看資源的文檔
  get            顯示一個或更多 resources
  edit           在服務器上編輯一個資源
  delete    根據filenames, stdin, resources and names, or by resources and label selector刪除資源
 
Deploy Commands:
  rollout        Manage the rollout of a resource
  scale          爲 Deployment, ReplicaSet, Replication Controller 或者 Job 設置一個新的副本數量
  autoscale      自動調整一個 Deployment, ReplicaSet, 或者 ReplicationController 的副本數量
 
Cluster Management Commands:
  certificate    修改 certificate 資源.
  cluster-info   顯示集羣信息
  top            Display Resource (CPU/Memory/Storage) usage.
  cordon         標記 node 爲 unschedulable
  uncordon       標記 node 爲 schedulable
  drain          Drain node in preparation for maintenance 耗盡node
  taint          更新一個或者多個 node 上的 taints
 
Troubleshooting and Debugging Commands:
  describe       顯示一個指定 resource 或者 group 的 resources 詳情
  logs           輸出容器在 pod 中的日誌
  attach         Attach 到一個運行中的 container
  exec           在一個 container 中執行一個命令
  port-forward   Forward one or more local ports to a pod
  proxy          運行一個 proxy 到 Kubernetes API server
  cp             複製 files 和 directories 到 containers 和從容器中複製 files 和 directories.
  auth           Inspect authorization
 
Advanced Commands:
  apply          經過配置文件或標準輸入流(stdin)對資源進行配置
  patch          使用 strategic merge patch 更新一個資源的 field(s)
  replace        經過 filename 或者 stdin替換一個資源
  wait           Experimental: Wait for one condition on one or many resources
  convert        在不一樣的 API versions 轉換配置文件
 
Settings Commands:
  label          更新在這個資源上的 labels
  annotate       更新一個資源的註解
  completion     Output shell completion code for the specified shell (bash or zsh)
 
Other Commands:
  alpha          Commands for features in alpha
  api-resources      Print the supported API resources on the server
  api-versions       Print the supported API versions on the server, in the form of "group/version"
  config         修改 kubeconfig 文件
  plugin         Runs a command-line plugin
  version        輸出 client 和 server 的版本信息

TYPE：指定資源類型，資源類型是大小寫敏感的，開發者可以以單數、複數和縮略的形式。例如：

kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1

NAME：指定資源的名稱，名稱大小寫敏感。若省略名稱，則會顯示全部資源，例如：

kubectl get pods

flags：指定可選的參數。例如，可使用-s或者--server參數指定kubernetes API server的地址和端口。

3.2 kubectl經常使用命令

kubectl做爲kubernetes的命令行工具，主要的職責就是對集羣中的資源的對象進行操做，這些操做包括對資源對象的建立、刪除和查看等。下表中顯示了kubectl支持的全部操做，以及這些操做的語法和描述信息：

kubectl編輯配置

kubectl edit (RESOURCE/NAME | -f FILENAME) [options]
$kubectl get deployment -o wide
NAME         READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES   SELECTOR
nginx-test   2/3     3            2           4d18h   nginx-test   nginx    app=nginx
$kubectl edit deployment nginx-test
deployment.extensions/nginx-test edited
$ kubectl get deployment -o wide
NAME         READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES   SELECTOR
nginx-test   2/2     2            2           4d18h   nginx-test   nginx    app=nginx

kubectl輸出選項

kubectl默認的輸出格式爲純文本格式，能夠經過-o或者–output字段指定命令的輸出格式。

kubectl [command] [TYPE] [NAME] -o=<output format>
kubectl get pod nginx-test-xxxxxxxxx -o yaml

3.3 k8s支持的資源

$ kubectl api-resources

NAME                              SHORTNAMES   APIGROUP                       NAMESPACED   KIND
bindings                                                                      true         Binding
componentstatuses                 cs                                          false        ComponentStatus
configmaps                        cm                                          true         ConfigMap
endpoints                         ep                                          true         Endpoints
events                            ev                                          true         Event
limitranges                       limits                                      true         LimitRange
namespaces                        ns                                          false        Namespace
nodes                             no                                          false        Node
persistentvolumeclaims            pvc                                         true         PersistentVolumeClaim
persistentvolumes                 pv                                          false        PersistentVolume
pods                              po                                          true         Pod
podtemplates                                                                  true         PodTemplate
replicationcontrollers            rc                                          true         ReplicationController
resourcequotas                    quota                                       true         ResourceQuota
secrets                                                                       true         Secret
serviceaccounts                   sa                                          true         ServiceAccount
services                          svc                                         true         Service
mutatingwebhookconfigurations                  admissionregistration.k8s.io   false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io   false        ValidatingWebhookConfiguration
customresourcedefinitions         crd,crds     apiextensions.k8s.io           false        CustomResourceDefinition
apiservices                                    apiregistration.k8s.io         false        APIService
controllerrevisions                            apps                           true         ControllerRevision
daemonsets                        ds           apps                           true         DaemonSet
deployments                       deploy       apps                           true         Deployment
replicasets                       rs           apps                           true         ReplicaSet
statefulsets                      sts          apps                           true         StatefulSet
tokenreviews                                   authentication.k8s.io          false        TokenReview
localsubjectaccessreviews                      authorization.k8s.io           true         LocalSubjectAccessReview
selfsubjectaccessreviews                       authorization.k8s.io           false        SelfSubjectAccessReview
selfsubjectrulesreviews                        authorization.k8s.io           false        SelfSubjectRulesReview
subjectaccessreviews                           authorization.k8s.io           false        SubjectAccessReview
horizontalpodautoscalers          hpa          autoscaling                    true         HorizontalPodAutoscaler
cronjobs                          cj           batch                          true         CronJob
jobs                                           batch                          true         Job
certificatesigningrequests        csr          certificates.k8s.io            false        CertificateSigningRequest
daemonsets                        ds           extensions                     true         DaemonSet
deployments                       deploy       extensions                     true         Deployment
ingresses                         ing          extensions                     true         Ingress
networkpolicies                   netpol       extensions                     true         NetworkPolicy
podsecuritypolicies               psp          extensions                     false        PodSecurityPolicy
replicasets                       rs           extensions                     true         ReplicaSet
addons                                         k3s.cattle.io                  true         Addon
helmcharts                                     k3s.cattle.io                  true         HelmChart
listenerconfigs                                k3s.cattle.io                  true         ListenerConfig
networkpolicies                   netpol       networking.k8s.io              true         NetworkPolicy
poddisruptionbudgets              pdb          policy                         true         PodDisruptionBudget
podsecuritypolicies               psp          policy                         false        PodSecurityPolicy
clusterrolebindings                            rbac.authorization.k8s.io      false        ClusterRoleBinding
clusterroles                                   rbac.authorization.k8s.io      false        ClusterRole
rolebindings                                   rbac.authorization.k8s.io      true         RoleBinding
roles                                          rbac.authorization.k8s.io      true         Role
priorityclasses                   pc           scheduling.k8s.io              false        PriorityClass
storageclasses                    sc           storage.k8s.io                 false        StorageClass
volumeattachments                              storage.k8s.io                 false        VolumeAttachment

3.4 kubeconfig

kubectl默認會從$HOME/.kube目錄下查找文件名爲config的文件，也能經過設置環境變量KUBECONFIG或者經過設置去指定其它 kubeconfig 文件。kubeconfig就是爲訪問集羣所做的配置。

在開啓了 TLS 的集羣中，每當與集羣交互的時候少不了的是身份認證，使用 kubeconfig（即證書）和 token 兩種認證方式是最簡單也最通用的認證方式。

kubectl config SUBCOMMAND [options]
kubectl options
      --alsologtostderr[=false]: 同時輸出日誌到標準錯誤控制檯和文件｡
      --api-version="": 和服務端交互使用的API版本。
      --certificate-authority="": 用以進行認證受權的.cert文件路徑。
      --client-certificate="": TLS使用的客戶端證書路徑。
      --client-key="": TLS使用的客戶端密鑰路徑。
      --cluster="": 指定使用的kubeconfig配置文件中的集羣名。
      --context="": 指定使用的kubeconfig配置文件中的環境名。
      --insecure-skip-tls-verify[=false]: 若是爲true，將不會檢查服務器憑證的有效性，
                                          這會致使你的HTTPS連接變得不安全。
      --kubeconfig="": 命令行請求使用的配置文件路徑。
      --log-backtrace-at=:0: 當日志長度超過定義的行數時，忽略堆棧信息。
      --log-dir="": 若是不爲空，將日誌文件寫入此目錄。
      --log-flush-frequency=5s: 刷新日誌的最大時間間隔。
      --logtostderr[=true]: 輸出日誌到標準錯誤控制檯，不輸出到文件。
      --match-server-version[=false]: 要求服務端和客戶端版本匹配。
      --namespace="": 若是不爲空，命令將使用此namespace。
      --password="": API Server進行簡單認證使用的密碼。
  -s, --server="": Kubernetes API Server的地址和端口號。
      --stderrthreshold=2: 高於此級別的日誌將被輸出到錯誤控制檯。
      --token="": 認證到API Server使用的令牌。
      --user="": 指定使用的kubeconfig配置文件中的用戶名。
      --username="": API Server進行簡單認證使用的用戶名。
      --v=0: 指定輸出日誌的級別。
      --vmodule=: 指定輸出日誌的模塊，格式以下：pattern=N，使用逗號分隔。

四． Kubernetes API

4.1 REST簡述

REST（Representational State Transfer）只是爲分佈式超媒體系統設計的一種架構風格，而不是標準。基於Web的架構實際上就是各類規範的集合，這些規範共同組成了Web架構，好比HTTP、CS模式都是規範。每當咱們在原有規範的基礎上增長新的規範時，就會造成新的架構。而REST正是這樣一種架構，它結合了一系列規範，造成了一種新的基於Web的架構風格。

傳統的web應用大可能是BS架構，涉及以下規範：1）客戶-服務器；2）無狀態性；3）緩存。REST才BS架構基礎上增長了三個新規範：統一接口、分層系統和按需代碼。

統一接口：REST架構風格的核心特徵就是強調組件之間有一個統一的接口，表現爲再REST世界裏，網絡上的全部事物都被抽象爲資源，REST經過通用的鏈接器接口對資源進行操做。這樣設計的好處是保證系統提供的服務都是解耦的，極大地簡化了系統，從而改善了系統的交互性和可重用性。
分層系統：分層系統規則的加入提升了各類層次之間的獨立性，爲整個系統的複雜性設置了邊界，經過封裝遺留的服務，使新的服務器免受遺留客戶端的影響，提升了系統的可伸縮性。
按需代碼：REST容許對客戶端功能進行擴展。好比，經過下載並執行applet或腳本形式的代碼來擴展客戶端的功能。但這在改善系統可擴展性的同時下降了可見性，因此只是REST的一個可選約束。

REST架構是針對Web應用而設計的，目的是爲了下降開發的複雜性，提供系統的可伸縮性。REST提出以下設計準則：

網絡上全部事物都被抽象爲資源（resource）。
每一個資源對應一個惟一的資源標識符（Resource identifier）。
經過通用的鏈接器接口對資源進行操做。
對資源的各類操做不會改變資源標識符。
全部的操做都是無狀態的。

REST是基於HTTP的，全部對資源的操做行爲都經過HTTP實現。HTTP把對一個資源的操做限制在4種方法內：GET、POST、PUT和DELETE。

REST之因此能夠提升系統的可伸縮性，就是由於它要求全部操做都是無狀態的。因爲沒有上下文的約束，作分佈式和集羣時更簡單，也能夠有效地利用緩衝池（Pool），而且因爲服務器端不須要記錄客戶端的一系列訪問，也就減小了服務器端的性能損耗。

4.2 K8S API概述

K8S API採用REST架構設計。k8s開發團隊基於API級別選擇版本而不是基於資源和域級別。

API資源使用REST模式，說明以下：

GET /<資源名的複數格式>：獲取某一類型的資源列表。
POST /<資源名的複數格式>：建立一個資源，該資源來自用戶提供的JSON對象。
GET /<資源名的複數格式>/<名字>：經過給出的名稱獲取單個資源。
DELETE /<資源名的複數格式>/<名字>：經過給出的名字刪除單個資源。
PUT /<資源名的複數格式>/<名字>：功能經過給出的資源名和客戶端提供的JSON對象來更新或建立資源。
PATCH /<資源名的複數格式>/<名字>：選擇修改資源詳細指定的域。
GET /watch/<資源名的複數格式>：隨着時間變化，不斷接受一連串的JSON對象，這些JSON對象記錄了給定資源類別內全部資源對象的變化狀況。
GET /watch/<資源名的複數格式>/<name>：隨着時間變化，不斷接受一連串的JSON對象，這些JSON對象記錄了某個給定資源對象的變化狀況。

其中，watch是k8s經過的「觀察者」模式API接口，watch返回的是一連串JSON對象。

K8S API提供三種訪問方式：

k8s API server經過一個名爲kube-apiserver的進程提供服務，運行在master節點上。非安全端口（--insecure-port）8080，安全端口（--secure-port）6443提供服務。
若是隻想對外暴露部分REST服務，能夠在master或其餘任何節點上經過運行kubectl Proxy進程啓動一個內部代理。如在8001端口啓動代理，而且拒絕客戶端訪問RC的API：

#kubectl proxy --reject-paths="^/api/v1/replicationcontrollers" --port=8001 --v=2

經過編程方式調用kubernetes API server。1）運行在Pod裏的用戶進程調用kubernetes API，一般用來實現分佈式集羣搭建的目標。2）開發基於kubernetes的管理平臺，好比調用kubernetes API來完成Pod、Service、RC等資源對象的圖形化建立和管理界面。可使用kubernetes提供的Client Library。

api路徑參考：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/

/api/v1/nodes

/api/v1/namespaces/{namespace}/pods

/api/v1/namespaces/{namespace}/services

4.3 k8s Proxy API

k8s API server最主要的REST接口是資源對象的增、刪、改、查，此外還提供一類很特殊的REST接口--K8s Proxy API接口，這類接口的做用是代理REST請求，即K8s API Server把收到的REST請求轉發到某個Node上的kubelet守護進程的REST端口上，由該kubelet進程負責響應。

node接口

/api/v1/proxy/nodes/{name}/pods/ #列出指定節點內全部Pod的信息

/api/v1/proxy/nodes/{name}/stats/ #列出指定節點內物理資源的統計信息

/api/v1/prxoy/nodes/{name}/spec/ #列出指定節點的概要信息

k8s pod接口

/api/v1/proxy/namespaces/{namespace}/pods/{name} #訪問pod

/api/v1/proxy/namespaces/{namespace}/pods/{name}/{path:*} #訪問pod的某個服務接口

做用：在k8s集羣以外訪問某個Pod容器的服務時，可使用Proxy API實現，這種場景多用於管理目的。

k8s Service接口

/api/v1/proxy/namespaces/{namespace}/services/{name}

4.4 集羣功能模塊之間的通訊

k8s API server做爲集羣的核心，負責集羣各功能模塊之間的通訊。集羣內的各個功能模塊經過API Server將信息存入etcd，當須要獲取和操做這些數據時，經過API server提供的REST接口來實現，從而實現各模塊之間的信息交互。

常見的一個交互場景是kubelet進程與API Server的交互。每一個Node節點上的kubelet每隔一個時間週期，就會調用一次API server的REST接口報告自身狀態，API server接收到這些信息後，將節點狀態信息更新到etcd中。

五． YAML文件應用

當建立好一個k8s集羣后，須要一個deployment，告訴k8s mater如何去建立應用，也能夠更新應用。

Service 是一個抽象的概念，它定義了一組邏輯 Pods，而且提供訪問它們的策略。

deployment和service等對象均可以經過kubectl或者YAML建立。先看一個YAML文件示例：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: IfNotPresent
        name: nginx-test
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-test
spec:
  ports:
  - name: nginx-test
    port: 80
    targetPort: 80
  selector:
    app: nginx

可用以下命令應用此yaml文件並測試：

kubectl apply -f nginx-test.yaml
kubectl get pods -o wide

也能夠直接拷貝此文件到manifests目錄/var/lib/rancher/k3s/server/manifests/下讓k8s自動管理。

通常yaml文件會包含以下幾個基本參數：

1）apiVersion：接口版本，如今通常都寫v1，但它是隨着安裝Kubernetes和資源類型的變化而變化的。

2）kind：正在建立哪一種對象object。如Pod，Deployment、Job、Ingress、Service等。

3）metadata：元數據，惟一肯定對象，如名稱、namespace、標籤等。

4）spec：每種object對象的spec格式都不一樣，且包含嵌套域field。Kubernetes API Reference提供了全部可用對象的spec格式。如Pod，Deployment。可經過命令kubectl api-resources獲取k8s支持的全部object。

六．kubeadm安裝k8s集羣

sudo kubeadm init --kubernetes-version=v1.14.1 
[init] Using Kubernetes version: v1.14.1
[preflight] Running pre-flight checks
    [WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Activating the kubelet service
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [ubuntu-wang localhost] and IPs [192.168.134.144 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [ubuntu-wang localhost] and IPs [192.168.134.144 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [ubuntu-wang kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.134.144]
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 18.010320 seconds
[upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.14" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --experimental-upload-certs
[mark-control-plane] Marking the node ubuntu-wang as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node ubuntu-wang as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: pu42jk.paf8g74hs9acbi19
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.134.144:6443 --token pu42jk.paf8g74hs9acbi19 \
    --discovery-token-ca-cert-hash sha256:98f674ab4e52f10826d5c6ad0f67f73e5f377c6aa3044372234a0ed6114ebd9b

七. dashboard
dashboard git官網https://github.com/kubernetes/dashboard,爲k8s提供了一個管理UI。

7.1 安裝dashboard

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml

7.2 dashboard訪問

認證方式有Kubeconfig和令牌兩種方式，訪問方式有四種：NodePort、APIServer、kubectl proxy、Ingress。

NodePort方式登陸

修改kubernetes-dashboard.yaml的service的type爲NodePort，nodePort可設爲30000。

# ------------------- Dashboard Service ------------------- #
kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system
spec:
  ports:
    - port: 443
      targetPort: 8443
      nodePort: 30000
  selector:
    k8s-app: kubernetes-dashboard
  type: NodePort

kubectl get svc -n kube-system獲取服務端口，直接訪問端口：

https://172.61.1.63:30000

此時有默認用戶kubernetes-dashboard，權限爲kubernetes-dashboard-minimal，訪問受限。

能夠建立一個高權限用戶admin-user管理k8s，權限爲cluster-admin：

$cat admin-user-sa-rbac.yaml 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kube-system

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kube-system

建立完成後應用token：

$ kubectl apply -f admin-user-sa-rbac.yaml
$ kubectl get pod -n kube-system|grep dashboard
$ kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')

獲取到token後用令牌方式登陸。

kubeconfig登陸

拷貝文件/etc/rancher/k3s/k3s.yaml，在最後加上token：***，下載到電腦本地。

八．k3s

k3s官網：https://k3s.io，github網站地址：https://github.com/rancher/k3s，目前github上提供不一樣平臺的二進制文件；docker鏡像網址：https://hub.docker.com/r/rancher/k3s/tags，提供不一樣平臺的docker鏡像。

啓動master：（docker或containerd虛擬化方式，默認採用containerd）

k3s server --docker
或
k3s server --kube-apiserver-arg service-node-port-range=3000-60003

node加入集羣：

k3s agent --docker -s https://192.168.134.140:6443 -t K1032decaad08cc4f82957538ae1c4008eb4587907dfb1930811e947bcf7c0b350d::node:c5989d78e810123f52a00ec00987d98b

注：應用中必定要將主機名加入到文件/etc/hosts中

# cat /etc/hosts 
127.0.0.1 localhost
127.0.0.1 openwrt-adb4

k8s運行須要相關組件，k3s也以tar形式提供，名爲k3s-airgap-images-$ARCH.tar，在啓動pod前拷貝到/var/lib/rancher/k3s/agent/images目錄下便可。

api訪問：https://192.168.134.140:6443/api/v1/nodes

參考：

K8S基礎概念博主有多篇k8s博文
https://kubernetes.io/zh/docs/concepts/
Understanding Kubernetes Objects k8s官網理解對象
認識kubernetes https://kubernetes.io/zh/docs/concepts/overview/what-is-kubernetes/
Kubernetes API Reference YAML配置文件各字段定義說明
https://kubernetes.io/docs/concepts/containers/images/
Kubernetes網絡模型概念
樹莓派3B+使用 kubeadm部署 kubernetes-1.12.0
Kubernetes之 kubectl命令行工具簡介、安裝配置及經常使用命令
Kubernetes之 Pod、 Replicaset、 Service、Deployment和 Label
kubeconfig的用法及生成配置文件
Kubernetes 如何打贏容器之戰？https://mp.weixin.qq.com/s/4e9l-GP22T-myP54hJJjPA 原理入門
rancher使用博文
kubernetes cni網絡詳解
K8S 從懵圈到熟練：讀懂此文，集羣節點不下線！
Kubernetes之 APIServer組件簡介
從零開始搭建K8S--搭建 K8S Dashboard
kubernetes入門到精通

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。