上一節我們已經學習了原型模式，稍微複習一下：通過重寫Object 類的clone() 方法實現淺克隆，淺克隆也要實現Cloneable 標記接口。而深克隆則是將對象通過序列化和反序列化 的方式進行創建和還原。

本小結將學習的是工廠模式，這個模式在平時是特別常用的，還需好好理解。我也將舉一些例子給大家
、

從生活出發

假設我們今天不想做飯，想出去吃飯、肯定選定一家好吃的川菜館,然後我們找好位置坐下，給廚師說，我想吃糖醋排骨。 稍微等待幾分鐘、菜就可以做好，然後給你呈上來。

這是一個很經典的例子，我們平時也經常有這樣的實際問題，你發現了么？

• 我只需要告訴廚師菜名，我要吃啥就行了
• 我不關注這個菜是怎麼生產的 new()

開始擼代碼

/**
 * 抽象產品 菜
 */
public interface FoodProduct {
    void show();
}
------------
/**
 * 具體產品
 */
public class HongShao implements FoodProduct {
    @Override
    public void show() {
        System.out.println("紅燒排骨");
    }
}
------------
public class TangCu implements FoodProduct {
    @Override
    public void show() {
        System.out.println("糖醋魚");
    }
}

創建廚房工廠

創建一個廚房類，廚房可以用來生產食物產品，我們只需要告訴廚房，這裡是通過id 編號的形式告訴廚房的。我們只需要告訴廚房所需要的食物 而不關心這個食物產品是如何創建出來的。

public class KitchenFactory {
    /**
     * id=1 上菜紅燒肉 id=2 糖醋魚
     * @param id
     */
    public FoodProduct cooking(int id) {
        if (1 == id) {
            return new HongShao();
        } else {
            return new TangCu();
        }
    }
}

KitchenFactory kitchen = new KitchenFactory();
FoodProduct food = kitchen.cooking(1);
food.show();
--------
紅燒排骨

理解工廠模式

通過這個簡單的例子，我們可以學習到：

• 無需關注對象是如何創建的。只需通過指定的關鍵字 就能拿到我需要的產品，這就是簡單工廠模式。

抽象工廠

http://c.biancheng.net/view/1351.html

抽象工廠，就是簡單工廠的抽象版、如何理解呢？我們上面的工廠（廚房）它已經是一個確定的對象 了。而抽象工廠，則是在廚房 的基礎上，再次衍生出一個接口，我們的廚房 則是這個抽象類的一個具體實例化。

代碼源於生活

我又要開始舉栗子了。請細細品

我們都知道小米 小米既可以生產手機 也可以生產電器用品 那麼這就是一個很好的例子。

小米抽象工廠 是一個巨大的工廠，它裏面有小米手機工廠 以及小米電器工廠 而不同的工廠，則生產不同的產品。

代碼教學開始

首先，我們得需要一個抽象工廠，這個工廠可以包含手機工廠和電器工廠。

public interface AbstractFactory {
    /**
     * 創建手機工廠
     * @return
     */
    PhoneFactory phoneFactory();
    /**
     * 創建電器工廠
     * @return
     */
    ElectricalFactory electricalFactory();
}

當然，手機工廠不知道是具體哪個工廠，反正它可以做一些事情，比如創建手機。

public interface PhoneFactory {
    /**
     * 手機工廠可以做的事情
     */
    void show();
}
-----------
public interface ElectricalFactory {
    /**
     * 電器工廠可以生產電器
     */
    void show();
}

上手實際創建一個小米工廠

public class XiaoMiFactory implements AbstractFactory {
    
    @Override
    public PhoneFactory phoneFactory() {
        return new XiaoMiPhoneFactory();
    }
    @Override
    public ElectricalFactory electricalFactory() {
        return new XiaoMiElectricalFactory();
    }
}
-------------
public class XiaoMiElectricalFactory implements ElectricalFactory {
    @Override
    public void show() {
        System.out.println("小米電器工廠可以生產電器。。比如小米掃地機器人");
    }
}
-------------
public class XiaoMiPhoneFactory implements PhoneFactory {
    @Override
    public void show() {
        System.out.println("小米手機工廠可以生產小米手機。。。");
    }
}

當然，小米工廠實現抽象工廠，那小米工廠就必須要包含兩個子工廠，手機工廠和電器工廠了。我們也可以創建一個華為工廠，其實是一樣的道理。

AbstractFactory factory = new XiaoMiFactory();

PhoneFactory phoneFactory = factory.phoneFactory();
phoneFactory.show();
--------
小米手機工廠可以生產小米手機。。。

我們從創建的小米工廠中拿出小米手機工廠 然後再執行手機工廠可以做事情，抽象工廠，就是在上面的簡單工廠的層次上進行了再次的抽象，將具體的工廠進行抽象。

假設我們按照上面的邏輯。對於一個工廠，我想要一部手機 我給工廠說一聲就行了。我不關心這個手機 是如何生產出來的。我該怎麼操作？

我稍微將之前的幾個接口作為稍微的改造。

public interface PhoneFactory {
    /**
     * 手機工廠可以做的事情
     */
    PhoneProduct show();
}
---------------
public class XiaoMiPhoneFactory implements PhoneFactory {
    @Override
    public PhoneProduct show() {
        return new PhoneProduct(1, "小米10 Pro");
    }
}
----------
//手機對象
public class PhoneProduct {

    private int id;

    private String name;
}

我們可以創建這樣一個訪問器，通過訪問器對象，將我們需要的對象名稱傳入就好比下單 它能自動匹配工廠，並且調用工廠創建產品 的方法，將我們需要的產品進行創建。

public class AbstractFactoryClient {

    public PhoneProduct createPhone(String name) {

        AbstractFactory factory = null;

        if ("xiaomi" == name) {
            factory = new XiaoMiFactory();
        } else {
            factory = new HuaweiFactory();
        }
        PhoneFactory phoneFactory = factory.phoneFactory();
        
        return phoneFactory.show();
    }
}

測試一下

AbstractFactoryClient factoryClient = new AbstractFactoryClient();
PhoneProduct product = factoryClient.createPhone("xiaomi");
System.out.println(product);
-----------
手機銘牌 編號：1,型號：小米10 Pro

小結

學習完本節，是否對於工廠模式和抽象工廠有了一個深入的了解呢？工廠模式其實在平時的代碼中，還是比較常用的。所以還是需要更加努力學習和使用！

代碼示例

https://gitee.com/mrc1999/Dev-Examples

參考

http://c.biancheng.net/view/1351.html

歡迎關注

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

背景

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 官網
譯者 ： 技術譯民
出品 ： 技術譯站
鏈接 ： 英文原文
公眾號：技術譯站

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案