背景

Kubernetes中的調度是將待處理的pod綁定到節點的過程，由Kubernetes的一個名為kube-scheduler的組件執行。調度程序的決定，無論是否可以或不能調度容器，都由其可配置策略指導，該策略包括一組規則，稱為謂詞和優先級。調度程序的決定受到其在第一次調度時出現新pod時的Kubernetes集群視圖的影響。由於Kubernetes集群非常動態且狀態隨時間而變化，因此可能需要將已經運行的pod移動到其他節點，原因如下：

• 一些節點不足或過度使用。
• 原始調度決策不再適用，因為在節點中添加或刪除了污點或標籤，不再滿足pod / node親和性要求。
• 某些節點發生故障，其pod已移至其他節點。
• 新節點將添加到群集中。

因此，可能會在群集中不太理想的節點上安排多個pod。Descheduler根據其政策，發現可以移動並移除它們的pod。請注意，在當前的實現中，descheduler不會安排更換被驅逐的pod，而是依賴於默認的調度程序。

Descheduler二次調度

GitHub地址：https://github.com/kubernetes-sigs/descheduler

下面是重要的配置

• configmap.yaml

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: descheduler-policy-configmap
  namespace: kube-system
data:
  policy.yaml: |
    apiVersion: "descheduler/v1alpha1"
    kind: "DeschedulerPolicy"
    strategies:
      "RemoveDuplicates":
         enabled: true
      "RemovePodsViolatingInterPodAntiAffinity":
         enabled: true
      "LowNodeUtilization":
         enabled: true
         params:
           nodeResourceUtilizationThresholds:
             thresholds:
               "cpu" : 30
               "memory": 40
               "pods": 50
             targetThresholds:
               "cpu" : 20
               "memory": 25
               "pods": 15

RemoveDuplicates策略

該策略發現未充分利用的節點，並且如果可能的話，從其他節點驅逐pod，希望在這些未充分利用的節點上安排被驅逐的pod的重新創建。此策略的參數配置在nodeResourceUtilizationThresholds。

節點的利用率低是由可配置的閾值決定的thresholds。thresholds可以按百分比為cpu，內存和pod數量配置閾值 。如果節點的使用率低於所有（cpu，內存和pod數）的閾值，則該節點被視為未充分利用。目前，pods的請求資源需求被考慮用於計算節點資源利用率。

還有另一個可配置的閾值，targetThresholds用於計算可以驅逐pod的潛在節點。任何節點，所述閾值之間，thresholds並且targetThresholds被視為適當地利用，並且不考慮驅逐。閾值targetThresholds也可以按百分比配置為cpu，內存和pod數量。

簡單的說：thresholds是沒有達到資源使用的node視為資源使用率低可以分配做為預選節點， targetThresholds是已經滿足這個條件的node資源緊張要把上面的pod遷移。

• cronjob.yaml

---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: descheduler-cronjob
  namespace: kube-system
spec:
　　#定時任務時間可調
  schedule: "*/10 * * * *"
  concurrencyPolicy: "Forbid"
  jobTemplate:
    spec:
      template:
        metadata:
          name: descheduler-pod
        spec:
          priorityClassName: system-cluster-critical
          containers:
          - name: descheduler
            image: aveshagarwal/descheduler
            #image: us.gcr.io/k8s-artifacts-prod/descheduler:v0.10.0
            volumeMounts:
            - mountPath: /policy-dir
              name: policy-volume
            command:
              - "/bin/descheduler"
            args:
              - "--policy-config-file"
              - "/policy-dir/policy.yaml"
              - "--v"
              - "3"
          restartPolicy: "Never"
          serviceAccountName: descheduler-sa
          volumes:
          - name: policy-volume
            configMap:
              name: descheduler-policy-configmap

• rbac.yaml

---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: descheduler-cluster-role
  namespace: kube-system
rules:
- apiGroups: [""]
  resources: ["events"]
  verbs: ["create", "update"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "delete"]
- apiGroups: [""]
  resources: ["pods/eviction"]
  verbs: ["create"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: descheduler-sa
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: descheduler-cluster-role-binding
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: descheduler-cluster-role
subjects:
  - name: descheduler-sa
    kind: ServiceAccount
    namespace: kube-system

kubectl apply -f 執行上面三個文件,查看日誌如有滿足再次調度條件的 會重新發起二次調度均衡node資源。

 

 

 

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

Docker 是一個開發、發布和運行應用程序的開放平台。Docker使您能夠將應用程序與基礎架構分離，以便快速交付軟件。有了 Docker，你可以像管理應用程序一樣管理你的基礎設施。通過利用 Docker 快速發布、測試和部署代碼的方法，您可以顯著減少編寫代碼和在生產環境中運行它之間的延遲。

Docker 平台

Docker 提供了在鬆散隔離的環境（稱為容器）中打包和運行應用程序的能力。隔離和安全性允許您在給定的主機上同時運行多個容器。容器是輕量級的，因為它們不需要額外的hypervisor負載，而是直接在主機的內核中運行。這意味着您可以在給定的硬件組合上運行比使用虛擬機時更多的容器。你甚至可以在實際是虛擬機的主機中運行 Docker 容器！

Docker 提供了工具和平台來管理容器的生命周期:

• 使用容器開發應用程序及其支持組件。
• 容器成為分發和測試應用程序的單元。
• 準備就緒后，將應用程序作為容器或編排好的服務部署到生產環境中。無論您的生產環境是本地數據中心、雲提供商還是兩者的混合，操作都是一樣的。

Docker 引擎

Docker 引擎是一個 客戶端-服務器 應用程序，具有以下主要組件:

• 一個服務器，它是一種稱為守護進程（dockerd 命令）的長時間運行程序。
• 一個 REST API，它指定程序可以用來與守護進程對話並指示它做什麼的接口。
• 一個命令行界面(CLI)客戶端(docker命令)。

CLI 使用Docker REST API通過腳本或直接CLI命令控制Docker守護進程或與之交互。
許多其他Docker應用程序使用底層API和CLI。

這個守護進程創建和管理 Docker 對象，如鏡像、容器、網絡和卷（images, containers, networks, and volumes）。

注意: Docker使用的是開源 Apache 2.0 許可證。

有關更多細節，請參閱下面的 Docker 架構。

我可以用 Docker 做什麼？

快速、一致地交付應用程序

Docker 允許開發人員使用提供應用程序和服務的本地容器，在標準化的環境中工作，從而簡化了開發生命周期。容器對於持續集成和持續交付(CI/CD)工作流非常有用。

考慮以下示例場景：

• 開發人員在本地編寫代碼，並使用 Docker 容器與同事共享他們的工作。
• 他們使用 Docker 將應用程序推送到測試環境，並執行自動和手動測試。
• 當開發人員發現 bug 時，他們可以在開發環境中修復它們，並將它們重新部署到測試環境中進行測試和驗證。
• 當測試完成時，向客戶提供修復就像將更新后的鏡像推送到生產環境一樣簡單。

響應式部署和擴展

Docker 的基於容器的平台允許高度可移植的工作負載。Docker 容器可以運行在開發人員的本地筆記本電腦上、數據中心的物理或虛擬機上、雲提供商上或在混合的環境中。

Docker 的可移植性和輕量級性質也使得它可以很容易地動態管理工作負載，根據業務需要，在接近實時的情況下擴展或拆除應用程序和服務。

在相同硬件上運行更多工作負載

Docker 是輕量級和快速的。它為基於管理程序的虛擬機提供了一種可行的、經濟有效的替代方案，因此您可以使用更多的計算能力來實現業務目標。Docker 非常適合高密度環境和中小型部署，在這些環境中，您需要用更少的資源做更多的事情。

Docker 架構

Docker 使用客戶端-服務器架構。Docker 客戶端與 Docker 守護進程通信，後者負責構建、運行和分發Docker 容器等繁重的工作。Docker 客戶端和守護進程可以運行在同一個系統上，或者您可以將一個 Docker 客戶端連接到一個遠程 Docker 守護進程。Docker 客戶端和守護進程通過 UNIX 套接字或網絡接口使用 REST API 進行通信。

Docker 守護進程

Docker 守護進程(dockerd)偵聽 Docker API 請求並管理 Docker 對象，如鏡像、容器、網絡和卷。
守護進程還可以與其他守護進程通信來管理 Docker 服務。

Docker 客戶端

Docker 客戶端(docker)是許多 Docker 用戶與 Docker 交互的主要方式。當您使用諸如docker run之類的命令時，客戶端將這些命令發送給dockerd, dockerd 會執行這些命令。docker 命令使用 Docker API。Docker 客戶端可以與多個守護進程通信。

Docker 註冊表

Docker 註冊表存儲 Docker 鏡像。
Docker Hub 是一個任何人都可以使用的公共註冊表，默認情況下 Docker 被配置為在 Docker Hub 上尋找鏡像。您甚至可以運行自己的私有註冊表。如果您使用 Docker 數據中心(DDC)，它包括 Docker 可信註冊表(DTR)。

當您使用 docker pull 或 docker run 命令時，所需的鏡像將從配置的註冊表中拉取。當您使用 docker push 命令時，您的鏡像將被推送到您配置的註冊表中。

Docker 對象

當您使用 Docker 時，您正在創建和使用鏡像、容器、網絡、卷、插件和其他對象。本節簡要介紹其中一些對象。

鏡像（IMAGES）

鏡像是一個只讀模板，帶有創建 Docker 容器的指令。鏡像通常基於另一個鏡像，並進行一些額外的定製。例如，您可以構建基於 ubuntu 鏡像的鏡像，但是安裝了 Apache web server 和您的應用程序，以及運行應用程序所需的配置細節。

您可以創建自己的鏡像，也可以只使用其他人創建併發布在註冊表中的鏡像。要構建自己的鏡像，需要創建一個 Dockerfile，其中包含一個簡單的語法，用於定義創建鏡像並運行它所需的步驟。Dockerfile 中的每條指令都會在鏡像中創建一個層。當你改變 Dockerfile 並重建鏡像時，只有那些已經改變的層才會重建。這是使鏡像與其他虛擬化技術相比如此輕量級、小巧和快速的原因之一。

容器（CONTAINERS）

容器是鏡像的可運行實例。您可以使用 Docker API 或 CLI 創建、啟動、停止、移動或刪除容器。您可以將一個容器連接到一個或多個網絡，將存儲附加到該容器，甚至基於其當前狀態創建一個新鏡像。

默認情況下，容器與其他容器及其主機相對隔離良好。您可以控制容器的網絡、存儲或其他底層子系統與其他容器或主機的隔離程度。

容器是由它的鏡像以及創建或啟動它時提供給它的任何配置選項定義的。當刪除容器時，對其狀態的任何未存儲在持久存儲中的更改都會消失。

docker run 命令示例

下面的命令運行一個 ubuntu 容器，以交互方式連接到本地命令行會話，並運行 /bin/bash。

$ docker run -i -t ubuntu /bin/bash

當你運行這個命令時，會發生以下情況(假設你使用默認的註冊表配置):

1. 如果你沒有本地的 ubuntu 鏡像，Docker會從你配置的註冊表中拉取它，就像你已經手動運行 docker pull ubuntu 一樣。
2. Docker 創建一個新的容器，就像手動運行 docker container create 命令一樣。
3. Docker 為容器分配一個讀寫文件系統，作為容器的最後一層。這允許運行中的容器在其本地文件系統中創建或修改文件和目錄。
4. Docker 創建一個網絡接口，將容器連接到默認網絡，因為您沒有指定任何網絡選項。這包括為容器分配IP地址。默認情況下，容器可以使用主機的網絡連接連接到外部網絡。
5. Docker 啟動容器並執行 /bin/bash。由於容器以交互方式運行並連接到你的終端(由於有-i和-t標誌)，所以可以將輸出記錄到終端，同時你可以使用鍵盤提供輸入。
6. 當您鍵入 exit 終止 /bin/bash 命令時，容器將停止，但不會被刪除。您可以重新啟動或刪除它。

服務（SERVICES）

服務允許您跨多個 Docker 守護進程擴展容器，這些守護進程組成一個集群，多個管理者和工作者一起工作。一個集群的每個成員都是一個 Docker 守護進程，所有的守護進程都使用 Docker API 進行通信。服務允許您定義所需的狀態，例如在任何給定時間必須可用的服務副本的數量。默認情況下，服務在所有工作節點之間進行負載均衡。對於消費者來說，Docker 服務看起來像一個單獨的應用程序。Docker 引擎在 Docker 1.12 及更高的版本支持集群模式。

底層技術

Docker 是用 Go 編寫的，並利用 Linux 內核的幾個特性來實現其功能。

命名空間

Docker 使用名為命名空間的技術來提供稱為容器的隔離工作區。當您運行一個容器時，Docker 為該容器創建一組命名空間。

這些命名空間提供了一個隔離層。容器的每個方面都在一個單獨的命名空間中運行，其訪問權限僅限於該命名空間。

Docker 引擎在 Linux 上使用如下命名空間:

• pid 命名空間: 進程隔離 (PID: 進程ID)。
• net 命名空間: 管理網絡接口 (NET: Networking)。
• ipc 命名空間: 管理對 IPC 資源的訪問 (IPC: 進程間通信)。
• mnt 命名空間: 管理文件系統掛載點 (MNT: Mount)。
• uts 命名空間: 隔離內核標識符和版本標識符 (UTS: Unix分時系統)。

控制組

Linux 上的 Docker 引擎還依賴於另一種稱為控制組(cgroups)的技術。cgroup 將應用程序限製為特定的資源集。控制組允許 Docker 引擎將可用的硬件資源共享給容器，並可以選擇強制限制和約束。例如，可以限制特定容器的可用內存。

聯合文件系統

聯合文件系統，或 UnionFS，是通過創建層來操作的文件系統，使其非常輕便和快速。Docker 引擎使用 UnionFS 為容器提供構建塊。Docker 引擎可以使用多種 UnionFS 變體，包括 AUFS、btrfs、vfs 和 DeviceMapper。

容器格式

Docker 引擎將命名空間、控制組和 UnionFS 組合到一個稱為容器格式的包裝器中。默認的容器格式是 libcontainer。未來，Docker 可能會通過與 BSD Jails 或 Solaris Zones 等技術集成來支持其他容器格式。

作者 ： Docker 官網
譯者 ： 技術譯民
出品 ： 技術譯站
鏈接 ： 英文原文
公眾號：技術譯站

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

C++和C#的前自增++n和后自增n++，都是先自增后取值和先取值后自增的含義，但在複雜一點的賦值語句中，我發現細節上有很大的差異。

發現這個問題主要是一個無聊的晚上，我想搞清楚后自增是什麼時候結算，自己搗鼓了一下之後我把我自己的測試結果告訴了朋友，結果學java的朋友和我爭論了半天，最後發現同樣的代碼，大家輸出是不一樣的。之後我又用了C#寫了同樣的測試代碼，發現輸出和他java是一樣的，這讓我豁然開朗，遂寫下這篇博客希望分享我的結論，如果有錯誤的話，歡迎評論區指正。

前排提醒：C++和C#我都是用的VS2017，不同編譯環境的C++代碼輸出結果可能不一樣

先說我的結論：

C++：i++遇到順序點（逗號，分號）之後i才自增，即我一直以來認為的一條語句結束后結算。但++i前自增的值會影響賦值語句所有i的值。

C#：C#不允許使用‘，’逗號運算符，但也並非到’;’分號才結算，賦值語句是從左到右，按序取值，i++在取完i的值之後馬上就自增了，但不影響之前取的i的值，隻影響後續i的取值。

心得：實際開發還是盡量自增單行寫，第一個是可讀性好，第二個是不容易出問題。（應該也就只有筆試會出現以下實驗的代碼了）

結論看不明白的可以看看我無聊的小實驗：

最簡單常見的版本：

int arr[] = { 0,0,0 };
int n = 0;
arr[n] = n++;//語句a
for (int num : arr)
{
	cout << num << ' ';
}
//輸出是0 0 0，語句a結束后n自增到1

上面這段代碼其實在C#也是一樣的輸出，但如果下面這樣寫，結果就不一樣了。

C++版：

int arr[] = { 0,0,0 };
int n = 0;
arr[n++] = n;//語句a
for (int num : arr)
{
	cout << num << ' ';
}
//輸出是0 0 0，語句a結束后n自增到1，C++結果和上面的一樣

C#版：

int[] arr = { 0, 0, 0 };
int n = 0;
arr[n++] = n;//語句a
foreach (int num in arr)
{
	Console.Write(num + " ");
}
//輸出是1 0 0，現在應該能理解結論了，從左到右，先取n作為索引值，然後自增之後影響到了等號右邊的n的值
//語句a則為arr[0] = 1;

就是這樣的差異開始引申出了問題，也是讓我迷惑的開始，接下來我會通過更複雜的例子和反彙編的指令來解釋和證明我的結論，先列舉C++的部分，之後再C#，感興趣的可以往下看。

C++部分：

//代碼01
int arr[] = { 0,0,0 };
int n = 0;
arr[n++] = n + (n++) + ++n;
for (int num : arr)
{
	cout << num << ' ';
}
//輸出為0 3 0，具體操作流程為語句先結算了++n，使得n自增到1.而出現的兩個n++都在賦值語句結束后結算
//所以編譯結果為arr[1] = 1 + 1 + 1; 然後i自增兩次到3

以下為反彙編的結果：

一開始看到這個我有點懵逼，但是通過比對下面這段代碼的反彙編指令，就能看出來了。

//代碼02
int[] arr = { 0, 0, 0 };
int n = 0;
arr[++n] = n + (n++) + ++n;//把索引處的n++改為了++n
foreach (int num in arr)
{
	Console.Write(num + " ");
}
//輸出為0 0 6，具體操作流程為語句先結算兩次++n，使得n自增到2.而n++在賦值語句結束后結算
//所以編譯結果為arr[2] = 2 + 2 + 2; 然後i自增到3
//這下應該發現n在這條語句中取值的時候都是同樣的值了

以下為上面代碼02的反彙編結果：

通過和上面的指令比對可以看出來了，具體差異在00251F3A這段指令，arr[++n]這段代碼02在累加前多進行了一次對n的自增，然後將自增后的值賦給了n，然後開始進行累加，而上面arr[n++]那段代碼01是在累加結束之後，在01161F4A那條指令對n++進行自增的結算，所以就算看不懂全部的指令，也應該能通過比對這兩段代碼看出他們的差異，從而證明了C++對於后自增的處理，是在語句結束之後結算。

說到語句結束，我之前寫了一篇關於逗號運算符的博客，可以結合今天這個結論看看下面這段代碼的輸出結果。

int arr[] = { 0,0,0 };
int n = 0;
arr[n] = (n++, n + (n++) + ++n);//在逗號左邊添加了n++的語句
for (int num : arr)
{
	cout << num << ' ';
}
//輸出為0 0 6
//原因為逗號也屬於一條語句結束的標誌，所以結算了n++，n=1，然後執行新的語句n + (n++) + ++n
//逗號右邊的語句先結算了++n，n=2，所以最後賦值語句為arr[2] = 2 + 2 + 2; 然後n++到3

至此C++的部分結束。

接下來C#的測試結果將顛覆上面的結論，如果不用java或者C#的話，下面的內容可能沒有用（朋友java的輸出結果和我C#一樣，不過也是希望大家自己試試，我自己沒有試過）

C#部分：

//代碼01 C#版
int[] arr = { 0, 0, 0 };
int n = 0;
arr[n++] = n + (n++) + ++n;
foreach (int num in arr)
{
	Console.Write(num + " ");
}
//輸出為5 0 0 和VC++完全不一樣對吧
//具體原因為C#的賦值語句是從左到右，先取了n的值作為索引，然後馬上對n自增，n=1
//來到等號右邊，第一個n取值為1，第二個n取值為1，然後自增到2，第三個n先自增到3，然後取值為3
//所以最終編譯結果為arr[0] = 1 + 1 + 3;  即5 0 0的原因
//為了節省篇幅，我直接告訴你arr[++n] = n + (n++) + ++n的結果為0 5 0，如果你上面看懂了這個應該也懂

貼一下C#這段代碼的反彙編結果：

可以看到第一行是取n的值，然後把n作為索引值，之後inc指令對n自增1。證明了上面的結論。

即：C#的賦值語句為從左到右，按序取值，n++在取完n的值之後馬上自增，但不影響之前取的值，隻影響後續n的取值。

小結：

所以++n 先自增后取值和n++ 先取值后自增是能直接套在C#上的，而對於VC++來說，后自增的結算是非常“緩慢”的，到語句結束才結算。

感謝您的觀看。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?