Kubernetes基礎-2

1.深入理解Pod對象

 1.Pod容器分類
      ? Infrastructure Container： 基礎容器
         ? 維護整個Pod網絡空間
      ? InitContainers： 初始化容器
             ? 先于業務容器開始執行
      ? Containers： 業務容器
          ? 并行啟動

     2.鏡像拉取策略
         ? IfNotPresent：默認值，鏡像在宿主機上不存在時才拉取
     ? Always：每次創建 Pod 都會重新拉取一次鏡像
     ? Never： Pod 永遠不會主動拉取這個鏡像

    3.資源限制
       Pod和Container的資源請求和限制：
 ? spec.containers[].resources.limits.cpu
 ? spec.containers[].resources.limits.memory
 ? spec.containers[].resources.requests.cpu
 ? spec.containers[].resources.requests.memory
     request可以理解為預分配，即判斷集群現有資源，limit和docker資源限制類似。

 4.重啟策略（restartPolicy）
    ? Always：當容器終止退出后，總是重啟容器，默認策略。
  ? OnFailure：當容器異常退出（退出狀態碼非0）時，才重啟容器。
  ? Never：當容器終止退出，從不重啟容器。

 5.健康檢查（Probe）

    Probe有以下兩種類型：
      livenessProbe
   如果檢查失敗，將殺死容器，根據Pod的restartPolicy來操作。
     readinessProbe
    如果檢查失敗， Kubernetes會把Pod從service endpoints中剔除。
 Probe支持以下三種檢查方法：

httpGet
發送HTTP請求， 返回200-400范圍狀態碼為成功。
exec
執行Shell命令返回狀態碼是0為成功。
tcpSocket
發起TCP Socket建立成功。
參考網站：https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

6.調度約束
? nodeName用于將Pod調度到指定的Node名稱上
? nodeSelector用于將Pod調度到匹配Label的Node上

7.故障排查

2.部署應用常用控制器

 1.Pod與controllers的關系

    ? controllers：在集群上管理和運行容器的對象
    ? 通過label-selector相關聯
    ? Pod通過控制器實現應用的運維，如伸縮，滾動升級等

    2.Deployment
       ? 部署無狀態應用
   ? 管理Pod和ReplicaSet
         ? 具有上線部署、副本設定、滾動升級、回滾等功能
       ? 提供聲明式更新，例如只更新一個新的Image
         應用場景： Web服務，微服務

    3.DaemonSet
      ? 在每一個Node上運行一個Pod
      ? 新加入的Node也同樣會自動運行一個Pod
            應用場景： Agent
             https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

    4.Job
       Job分為普通任務（Job）和定時任務（CronJob）
   ? 一次性執行
    應用場景：離線數據處理，視頻解碼等業務
            https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

    5.CronJob
       定時任務，像Linux的Crontab一樣。
     ? 定時任務
             應用場景：通知，備份
        https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

    6.Statefulset
       部署有狀態應用，需要考慮網絡ID 和存儲問題
          如mysql jenkins等

3.Service – 統一入口訪問應用

1.service簡介
? 防止Pod失聯（服務發現）
? 定義一組Pod的訪問策略（負載均衡）
? 支持ClusterIP， NodePort以及LoadBalancer三種類型
? Service的底層實現主要有iptables和ipvs二種網絡模式

2.Pod與Service的關系
   ? 通過label-selector相關聯
 ? 通過Service實現Pod的負載均衡（TCP/UDP 4層）

3.Service類型
   ClusterIP： 分配一個內部集群IP地址，只能在集群內部訪問（同Namespace內的Pod），默認ServiceType。
      ClusterIP 模式的 Service 為你提供的，就是一個 Pod 的穩定的 IP 地址，即 VIP。
 NodePort： 分配一個內部集群IP地址，并在每個節點上啟用一個端口來暴露服務，可以在集群外部訪問。
       訪問地址： <NodeIP>:<NodePort>
 LoadBalancer： 分配一個內部集群IP地址，并在每個節點上啟用一個端口來暴露服務。
     除此之外， Kubernetes會請求底層云平臺上的負載均衡器，將每個Node（[NodeIP]:[NodePort]）作為后端添加進去。一般云服務提供商支持，自建集群不支持該類型。

4.Service代理模式
        Iptables VS IPVS
   Iptables：

? 靈活，功能強大
? 規則遍歷匹配和更新，呈線性時延
? 可擴展性
IPVS：
? 工作在內核態，有更好的性能
? 調度算法豐富： rr， wrr， lc， wlc， ip hash...
默認是iptables模式，如果需要使用ipvs，需要修改configmap（kubeadm方式部署，如果是二進制，修改kube-proxy配置文件），服務器開啟ipvs。

 5.DNS
     DNS服務監視Kubernetes API，為每一個Service創建DNS記錄用于域名解析。
    ClusterIP A記錄格式： <service-name>.<namespace-name>.svc.cluster.local
   示例： my-svc.my-namespace.svc.cluster.local

小結：

1. 采用NodePort對外暴露應用，前面加一個LB實現統一訪問入口
   2. 優先使用IPVS代理模式
   3. 集群內應用采用DNS名稱訪問