<ul id="qxxfc"><fieldset id="qxxfc"><tr id="qxxfc"></tr></fieldset></ul>




      1 Pod - 實例


      Pod是一組緊密關聯(lián)的容器集合,支持多個容器在一個Pod中共享網(wǎng)絡和文件系統(tǒng),可以通過進程間通信和文件共享這種簡單高效的方式完成服務,是Kubernetes調度的基本單位。
      Pod的設計理念是 每個Pod都有一個唯一的IP

      Pod具有如下特征:

      * 包含多個共享IPC、Network和UTC namespace的容器,可直接通過localhost通信
      * 所有Pod內(nèi)容器都可以訪問共享的Volume,可以訪問共享數(shù)據(jù)
      * 優(yōu)雅終止:Pod刪除的時候先給其內(nèi)的進程發(fā)送SIGTERM,等待一段時間(grace period)后才強制停止依然還在運行的進程
      * 特權容器(通過SecurityContext配置)具有改變系統(tǒng)配置的權限(在網(wǎng)絡插件中大量應用)
      * 支持三種重啟策略(restartPolicy),分別是:Always、OnFailure、Never
      * 支持三種鏡像拉取策略(imagePullPolicy),分別是:Always、Never、IfNotPresent
      * 資源限制,Kubernetes通過CGroup限制容器的CPU以及內(nèi)存等資源,可以設置request以及l(fā)imit值
      *
      健康檢查,提供兩種健康檢查探針,分別是livenessProbe和redinessProbe,前者用于探測容器是否存活,如果探測失敗,則根據(jù)重啟策略進行重啟操作,后者用于檢查容器狀態(tài)是否正常,如果檢查容器狀態(tài)不正常,則請求不會到達該Pod
      * Init container在所有容器運行之前執(zhí)行,常用來初始化配置
      *
      容器生命周期鉤子函數(shù),用于監(jiān)聽容器生命周期的特定事件,并在事件發(fā)生時執(zhí)行已注冊的回調函數(shù),支持兩種鉤子函數(shù):postStart和preStop,前者是在容器啟動后執(zhí)行,后者是在容器停止前執(zhí)行
      2 Namespace - 命名空間


      Namespace(命名空間)是對一組資源和對象的抽象集合,比如可以用來將系統(tǒng)內(nèi)部的對象劃分為不同的項目組或者用戶組。常見的pod、service、replicaSet和deployment等都是屬于某一個namespace的(默認是default),而node,
      persistentVolumes等則不屬于任何namespace。

      常用namespace操作:
      # 查詢所有namespaces kubectl get namespace # 創(chuàng)建namespace kubectl create namespace
      ns-name # 刪除namespace kubectl delete namespace ns-name
      刪除命名空間時,需注意以下幾點:

      * 刪除一個namespace會自動刪除所有屬于該namespace的資源。
      * default 和 kube-system 命名空間不可刪除。
      * PersistentVolumes是不屬于任何namespace的,但PersistentVolumeClaim是屬于某個特定namespace的。
      * Events是否屬于namespace取決于產(chǎn)生events的對象。
      3 Node 節(jié)點

      Node是Pod真正運行的主機,可以是物理機也可以是虛擬機。Node本質上不是Kubernetes來創(chuàng)建的,
      Kubernetes只是管理Node上的資源。為了管理Pod,每個Node節(jié)點上至少需要運行container
      runtime(Docker)、kubelet和kube-proxy服務。

      常用node操作:
      # 查詢所有node kubectl get nodes # 將node標志為不可調度 kubectl cordon $nodename #
      將node標志為可調度 kubectl uncordon $nodename
      taint(污點)

      使用kubectl
      taint命令可以給某個Node節(jié)點設置污點,Node被設置上污點之后就和Pod之間存在了一種相斥的關系,可以讓Node拒絕Pod的調度執(zhí)行,甚至將Node已經(jīng)存在的Pod驅逐出去。每個污點的組成:
      key=value:effect,當前taint effect支持如下三個選項:

      * NoSchedule:表示k8s將不會將Pod調度到具有該污點的Node上
      * PreferNoSchedule:表示k8s將盡量避免將Pod調度到具有該污點的Node上
      * NoExecute:表示k8s將不會將Pod調度到具有該污點的Node上,同時會將Node上已經(jīng)存在的Pod驅逐出去
      常用命令如下:
      # 為節(jié)點node0設置不可調度污點 kubectl taint node node0 key1=value1:NoShedule #
      將node0上key值為key1的污點移除 kubectl taint node node0 key- # 為kube-master節(jié)點設置不可調度污點
      kubectl taint node node1 node-role.kubernetes.io/master=:NoSchedule #
      為kube-master節(jié)點設置盡量不可調度污點 kubectl taint node node1
      node-role.kubernetes.io/master=PreferNoSchedule
      容忍(Tolerations)


      設置了污點的Node將根據(jù)taint的effect:NoSchedule、PreferNoSchedule、NoExecute和Pod之間產(chǎn)生互斥的關系,Pod將在一定程度上不會被調度到Node上。
      但我們可以在Pod上設置容忍(Toleration),意思是設置了容忍的Pod將可以容忍污點的存在,可以被調度到存在污點的Node上。

      4 Service 服務

      Service是對一組提供相同功能的Pods的抽象,并為他們提供一個統(tǒng)一的入口,借助 Service
      應用可以方便的實現(xiàn)服務發(fā)現(xiàn)與負載均衡,并實現(xiàn)應用的零宕機升級。
      Service通過標簽(label)來選取后端Pod,一般配合ReplicaSet或者Deployment來保證后端容器的正常運行。

      service 有如下四種類型,默認是ClusterIP:

      * ClusterIP: 默認類型,自動分配一個僅集群內(nèi)部可以訪問的虛擬IP
      * NodePort: 在ClusterIP基礎上為Service在每臺機器上綁定一個端口,這樣就可以通過 NodeIP:NodePort 來訪問該服務
      * LoadBalancer: 在NodePort的基礎上,借助cloud provider創(chuàng)建一個外部的負載均衡器,并將請求轉發(fā)到
      NodeIP:NodePort
      * ExternalName: 將服務通過DNS CNAME記錄方式轉發(fā)到指定的域名
      另外,也可以將已有的服務以Service的形式加入到Kubernetes集群中來,只需要在創(chuàng)建 Service 的時候不指定Label
      selector,而是在Service創(chuàng)建好后手動為其添加endpoint。

      5 Volume 存儲卷


      默認情況下容器的數(shù)據(jù)是非持久化的,容器消亡以后數(shù)據(jù)也會跟著丟失,所以Docker提供了Volume機制以便將數(shù)據(jù)持久化存儲。Kubernetes提供了更強大的Volume機制和插件,解決了容器數(shù)據(jù)持久化以及容器間共享數(shù)據(jù)的問題。

      Kubernetes存儲卷的生命周期與Pod綁定

      * 容器掛掉后Kubelet再次重啟容器時,Volume的數(shù)據(jù)依然還在
      * Pod刪除時,Volume才會清理。數(shù)據(jù)是否丟失取決于具體的Volume類型,比如emptyDir的數(shù)據(jù)會丟失,而PV的數(shù)據(jù)則不會丟
      目前Kubernetes主要支持以下Volume類型:

      *
      emptyDir:Pod存在,emptyDir就會存在,容器掛掉不會引起emptyDir目錄下的數(shù)據(jù)丟失,但是pod被刪除或者遷移,emptyDir也會被刪除
      * hostPath:hostPath允許掛載Node上的文件系統(tǒng)到Pod里面去
      * NFS(Network File
      System):網(wǎng)絡文件系統(tǒng),Kubernetes中通過簡單地配置就可以掛載NFS到Pod中,而NFS中的數(shù)據(jù)是可以永久保存的,同時NFS支持同時寫操作。
      * glusterfs:同NFS一樣是一種網(wǎng)絡文件系統(tǒng),Kubernetes可以將glusterfs掛載到Pod中,并進行永久保存
      * cephfs:一種分布式網(wǎng)絡文件系統(tǒng),可以掛載到Pod中,并進行永久保存
      * subpath:Pod的多個容器使用同一個Volume時,會經(jīng)常用到
      * secret:密鑰管理,可以將敏感信息進行加密之后保存并掛載到Pod中
      * persistentVolumeClaim:用于將持久化存儲(PersistentVolume)掛載到Pod中
      ...

      6 PersistentVolume(PV) 持久化存儲卷

      PersistentVolume(PV)是集群之中的一塊網(wǎng)絡存儲。跟 Node 一樣,也是集群的資源。PersistentVolume
      (PV)和PersistentVolumeClaim (PVC)提供了方便的持久化卷: PV提供網(wǎng)絡存儲資源,而PVC請求存儲資源并將其掛載到Pod中。

      PV的訪問模式(accessModes)有三種:

      * ReadWriteOnce(RWO):是最基本的方式,可讀可寫,但只支持被單個Pod掛載。
      * ReadOnlyMany(ROX):可以以只讀的方式被多個Pod掛載。
      * ReadWriteMany(RWX):這種存儲可以以讀寫的方式被多個Pod共享。
      不是每一種存儲都支持這三種方式,像共享方式,目前支持的還比較少,比較常用的是 NFS。在PVC綁定PV時通常根據(jù)兩個條件來綁定,一個是存儲的大小,另一個就是
      訪問模式。

      PV的回收策略(persistentVolumeReclaimPolicy)也有三種

      * Retain,不清理保留Volume(需要手動清理)
      * Recycle,刪除數(shù)據(jù),即 rm -rf /thevolume/* (只有NFS和HostPath支持)
      * Delete,刪除存儲資源
      7 Deployment 無狀態(tài)應用


      一般情況下我們不需要手動創(chuàng)建Pod實例,而是采用更高一層的抽象或定義來管理Pod,針對無狀態(tài)類型的應用,Kubernetes使用Deloyment的Controller對象與之對應。其典型的應用場景包括:

      * 定義Deployment來創(chuàng)建Pod和ReplicaSet
      * 滾動升級和回滾應用
      * 擴容和縮容
      * 暫停和繼續(xù)Deployment
      常用的操作命令如下:
      # 生成一個Deployment對象 kubectl run www --image=10.0.0.183:5000/hanker/www:0.0.1
      --port=8080 # 查找Deployment kubectl get deployment --all-namespaces #
      查看某個Deployment kubectl describe deployment www # 編輯Deployment定義 kubectl edit
      deployment www # 刪除某Deployment kubectl delete deployment www #
      擴縮容操作,即修改Deployment下的Pod實例個數(shù) kubectl scale deployment/www --replicas=2 # 更新鏡像
      kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 # 回滾操作 kubectl
      rollout undo deployment/nginx-deployment # 查看回滾進度 kubectl rollout status
      deployment/nginx-deployment # 啟用水平伸縮(HPA - horizontal pod
      autoscaling),設置最小、最大實例數(shù)量以及目標cpu使用率 kubectl autoscale deployment
      nginx-deployment --min=10 --max=15 --cpu-percent=80 # 暫停更新Deployment kubectl
      rollout pause deployment/nginx-deployment # 恢復更新Deployment kubectl rollout
      resume deploy nginx
      更新策略

      .spec.strategy 指新的Pod替換舊的Pod的策略,有以下兩種類型

      * RollingUpdate 滾動升級,可以保證應用在升級期間,對外正常提供服務。
      * Recreate 重建策略,在創(chuàng)建出新的Pod之前會先殺掉所有已存在的Pod。
      Deployment和ReplicaSet兩者之間的關系

      * 使用Deployment來創(chuàng)建ReplicaSet。ReplicaSet在后臺創(chuàng)建pod,檢查啟動狀態(tài),看它是成功還是失敗。
      * 當執(zhí)行更新操作時,會創(chuàng)建一個新的ReplicaSet,Deployment會按照控制的速率將pod從舊的ReplicaSet移
      動到新的ReplicaSet中
      8 StatefulSet 有狀態(tài)應用

      Deployments和ReplicaSets是為無狀態(tài)服務設計的,那么StatefulSet則是為了有狀態(tài)服務而設計,其應用場景包括:

      * 穩(wěn)定的持久化存儲,即Pod重新調度后還是能訪問到相同的持久化數(shù)據(jù),基于PVC來實現(xiàn)
      * 穩(wěn)定的網(wǎng)絡標志,即Pod重新調度后其PodName和HostName不變,基于Headless Service(即沒有Cluster
      IP的Service)來實現(xiàn)
      *
      有序部署,有序擴展,即Pod是有順序的,在部署或者擴展的時候要依據(jù)定義的順序依次進行操作(即從0到N-1,在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態(tài)),基于init
      containers來實現(xiàn)
      * 有序收縮,有序刪除(即從N-1到0)
      支持兩種更新策略:

      * OnDelete:當.spec.template
      更新時,并不立即刪除舊的Pod,而是等待用戶手動刪除這些舊Pod后自動創(chuàng)建新Pod。這是默認的更新策略,兼容v1.6版本的行為
      * RollingUpdate:當 .spec.template
      更新時,自動刪除舊的Pod并創(chuàng)建新Pod替換。在更新時這些Pod是按逆序的方式進行,依次刪除、創(chuàng)建并等待Pod變成Ready狀態(tài)才進行下一個Pod的更新。
      9 DaemonSet 守護進程集

      DaemonSet保證在特定或所有Node節(jié)點上都運行一個Pod實例,常用來部署一些集群的日志采集、監(jiān)控或者其他系統(tǒng)管理應用。典型的應用包括:

      * 日志收集,比如fluentd,logstash等
      * 系統(tǒng)監(jiān)控,比如Prometheus Node Exporter,collectd等
      * 系統(tǒng)程序,比如kube-proxy, kube-dns, glusterd, ceph,ingress-controller等
      指定Node節(jié)點
      DaemonSet會忽略Node的unschedulable狀態(tài),有兩種方式來指定Pod只運行在指定的Node節(jié)點上:

      * nodeSelector:只調度到匹配指定label的Node上
      * nodeAffinity:功能更豐富的Node選擇器,比如支持集合操作
      * podAffinity:調度到滿足條件的Pod所在的Node上
      目前支持兩種策略

      * OnDelete: 默認策略,更新模板后,只有手動刪除了舊的Pod后才會創(chuàng)建新的Pod
      * RollingUpdate: 更新DaemonSet模版后,自動刪除舊的Pod并創(chuàng)建新的Pod
      10 Ingress 負載均衡

      Kubernetes中的負載均衡我們主要用到了以下兩種機制:

      * Service:使用Service提供集群內(nèi)部的負載均衡,Kube-proxy負責將service請求負載均衡到后端的Pod中
      * Ingress Controller:使用Ingress提供集群外部的負載均衡

      Service和Pod的IP僅可在集群內(nèi)部訪問。集群外部的請求需要通過負載均衡轉發(fā)到service所在節(jié)點暴露的端口上,然后再由kube-proxy通過邊緣路由器將其轉發(fā)到相關的Pod,Ingress可以給service提供集群外部訪問的URL、負載均衡、HTTP路由等,為了配置這些Ingress規(guī)則,集群管理員需要部署一個Ingress
      Controller,它監(jiān)聽Ingress和service的變化,并根據(jù)規(guī)則配置負載均衡并提供訪問入口。

      常用的ingress controller:

      * nginx
      * traefik
      * Kong
      * Openresty
      11 Job & CronJob 任務和定時任務

      Job負責批量處理短暫的一次性任務 (short lived one-off tasks),即僅執(zhí)行一次的任務,它保證批處理任務的一個或多個Pod成功結束。

      CronJob即定時任務,就類似于Linux系統(tǒng)的crontab,在指定的時間周期運行指定的任務。

      12 HPA(Horizontal Pod Autoscaling) 水平伸縮

      Horizontal Pod Autoscaling可以根據(jù)CPU、內(nèi)存使用率或應用自定義metrics自動擴展Pod數(shù)量 (支持replication
      controller、deployment和replica set)。

      * 控制管理器默認每隔30s查詢metrics的資源使用情況(可以通過 --horizontal-pod-autoscaler-sync-period
      修改)
      * 支持三種metrics類型
      1)預定義metrics(比如Pod的CPU)以利用率的方式計算

      2)自定義的Pod metrics,以原始值(raw value)的方式計算

      3)自定義的object metrics

      * 支持兩種metrics查詢方式:Heapster和自定義的REST API
      * 支持多metrics
      可以通過如下命令創(chuàng)建HPA:
      kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
      13 Service Account

      Service account是為了方便Pod里面的進程調用Kubernetes API或其他外部服務而設計的

      授權

      Service Account為服務提供了一種方便的認證機制,但它不關心授權的問題??梢耘浜蟁BAC(Role Based Access
      Control)來為Service
      Account鑒權,通過定義Role、RoleBinding、ClusterRole、ClusterRoleBinding來對sa進行授權。

      14 Secret 密鑰

      Sercert-密鑰解決了密碼、token、密鑰等敏感數(shù)據(jù)的配置問題,而不需要把這些敏感數(shù)據(jù)暴露到鏡像或者Pod
      Spec中。Secret可以以Volume或者環(huán)境變量的方式使用。有如下三種類型:

      * Service Account:用來訪問Kubernetes API,由Kubernetes自動創(chuàng)建,并且會自動掛載到Pod的
      /run/secrets/kubernetes.io/serviceaccount 目錄中;
      * Opaque:base64編碼格式的Secret,用來存儲密碼、密鑰等;
      * kubernetes.io/dockerconfigjson: 用來存儲私有docker registry的認證信息。
      15 ConfigMap 配置中心


      ConfigMap用于保存配置數(shù)據(jù)的鍵值對,可以用來保存單個屬性,也可以用來保存配置文件。ConfigMap跟secret很類似,但它可以更方便地處理不包含敏感信息的字符串。ConfigMap可以通過三種方式在Pod中使用,三種分別方式為:設置環(huán)境變量、設置容器命令行參數(shù)以及在Volume中直接掛載文件或目錄。

      可以使用 kubectl create configmap從文件、目錄或者key-value字符串創(chuàng)建等創(chuàng)建 ConfigMap。也可以通過 kubectl
      create -f value.yaml 創(chuàng)建。

      16 Resource Quotas 資源配額

      資源配額(Resource Quotas)是用來限制用戶資源用量的一種機制。

      資源配額有如下類型:

      * 計算資源,包括cpu和memory
      1)cpu, limits.cpu, requests.cpu

      2)memory, limits.memory, requests.memory

      * 存儲資源,包括存儲資源的總量以及指定storage class的總量
      1)requests.storage:存儲資源總量,如500Gi

      2)persistentvolumeclaims:pvc的個數(shù)

      3).storageclass.storage.k8s.io/requests.storage

      4).storageclass.storage.k8s.io/persistentvolumeclaims

      * 對象數(shù),即可創(chuàng)建的對象的個數(shù)
      1)pods, replicationcontrollers, configmaps, secrets

      2)resourcequotas, persistentvolumeclaims

      3)services, services.loadbalancers, services.nodeports

      它的工作原理為:

      資源配額應用在Namespace上,并且每個Namespace最多只能有一個 ResourceQuota 對象

      開啟計算資源配額后,創(chuàng)建容器時必須配置計算資源請求或限制(也可以 用LimitRange設置默認值)

      用戶超額后禁止創(chuàng)建新的資源

      友情鏈接
      ioDraw流程圖
      API參考文檔
      OK工具箱
      云服務器優(yōu)惠
      阿里云優(yōu)惠券
      騰訊云優(yōu)惠券
      京東云優(yōu)惠券
      站點信息
      問題反饋
      郵箱:[email protected]
      QQ群:637538335
      關注微信

        <ul id="qxxfc"><fieldset id="qxxfc"><tr id="qxxfc"></tr></fieldset></ul>
          欧美姓猛交ⅩXXX乱大交3 | 五月婷久操 | 久久精品嫩草影院 | 少妇三级高潮hd高清剧 | 师徒大尺度很肉污的小说 | 无码一区二区三区精品毛片一品国产 | 国产一级片免费看 | 日P动态图 | spa高潮按摩少妇金手指 99精品啪在线观看国产老湿机 | 啪啪黄色视频 |