国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

貓頭鷹的深夜翻譯:持久化容器存儲

xiao7cn / 2045人閱讀

摘要:如果我們的容器使用,文件如下在這個(gè)例子中,我們可以重復(fù)創(chuàng)建和銷毀,同一個(gè)持久存儲會被提供給新的,無論容器位于哪個(gè)節(jié)點(diǎn)上。

前言

臨時(shí)性存儲是容器的一個(gè)很大的買點(diǎn)。“根據(jù)一個(gè)鏡像啟動容器,隨意變更,然后停止變更重啟一個(gè)容器。你看,一個(gè)全新的文件系統(tǒng)又誕生了。”

在docker的語境下:

# docker run -it centos
[root@d42876f95c6a /]# echo "Hello world" > /hello-file
[root@d42876f95c6a /]# exit
exit
# docker run -it centos
[root@a0a93816fcfe /]# cat /hello-file
cat: /hello-file: No such file or directory

當(dāng)我們圍繞容器構(gòu)建應(yīng)用程序時(shí),這個(gè)臨時(shí)性存儲非常有用。它便于水平擴(kuò)展:我們只是從同一個(gè)鏡像創(chuàng)建多個(gè)容器實(shí)例,每個(gè)實(shí)例都有自己獨(dú)立的文件系統(tǒng)。它也易于升級:我們只是創(chuàng)建了一個(gè)新版本的映像,我們不必?fù)?dān)心從現(xiàn)有容器實(shí)例中保留任何內(nèi)容。它可以輕松地從單個(gè)系統(tǒng)移動到群集,或從內(nèi)部部署移動到云:我們只需要確保集群或云可以訪問registry中的鏡像。而且它易于恢復(fù):無論我們的程序崩潰對文件系統(tǒng)造成了什么損壞,我們只需要從鏡像重新啟動一個(gè)容器實(shí)例,之后就像從未發(fā)生過故障一樣。

因此,我們希望容器引擎依然提供臨時(shí)存儲。但是從教程示例轉(zhuǎn)換到實(shí)際應(yīng)用程序時(shí),我們確實(shí)會遇到問題。真實(shí)的應(yīng)用必修在某個(gè)地方存儲數(shù)據(jù)。通常,我們將狀態(tài)保存到某個(gè)數(shù)據(jù)存儲中(SQL或是NOSQL)。這也引來了同樣的問題。數(shù)據(jù)存儲也是位于容器中嗎?理想情況下,答案是肯定的,這樣我們可以利用和應(yīng)用層相同的滾動升級,冗余和故障轉(zhuǎn)移機(jī)制。但是,要在容器中運(yùn)行我們的數(shù)據(jù)存儲,我們再也不能滿足于臨時(shí)存儲。容器實(shí)例需要能夠訪問持久存儲。

如果使用docker管理持久性存儲,有兩種主流方案:我們可以在宿主機(jī)文件系統(tǒng)上指定一個(gè)目錄,或者是由Docker管理存儲:

# docker volume create data
data
# docker run -it -v data:/data centos
[root@5238393087ae /]# echo "Hello world" > /data/hello-file
[root@5238393087ae /]# exit
exit
# docker run -it -v data:/data centos
[root@e62608823cd0 /]# cat /data/hello-file
Hello world

Docker并不會保留第一個(gè)容器的根目錄,但是它會保留“data”卷。而該卷會被再次掛載到第二個(gè)容器上。所以該卷是持久存儲。

在單節(jié)點(diǎn)系統(tǒng)上這樣的方法是ok的。但是在一個(gè)容器集群環(huán)境下如Kubernetes或是Docker Swarm,情況會變得復(fù)雜。如果我們的數(shù)據(jù)存儲容器可能在上百個(gè)節(jié)點(diǎn)中的任意一個(gè)上啟動,而且可能從一個(gè)節(jié)點(diǎn)隨時(shí)遷移到另一個(gè)節(jié)點(diǎn),我們無法依賴于單一的文件系統(tǒng)來存儲數(shù)據(jù),我們需要一個(gè)能夠感知到容器的分部署存儲的方案,從而無縫集成。

容器持久化的需求

在深入容器持久化的方案之前,我們應(yīng)該先了解一下這個(gè)方案應(yīng)該滿足什么特性,從而更好的理解各種容器持久化方案的設(shè)計(jì)思路。

冗余

將應(yīng)用移動到容器中并且將容器部署到一個(gè)編排環(huán)境的原因在于我們可以有更多的物理節(jié)點(diǎn),從而可以支持部分節(jié)點(diǎn)當(dāng)?shù)簟M恚覀円蚕M志没鎯δ軌蛉萑檀疟P和節(jié)點(diǎn)的崩潰并且繼續(xù)支持應(yīng)用運(yùn)行。在持久化的場景下,冗余的需求更加重要了,因?yàn)槲覀儫o法忍受任何數(shù)據(jù)的丟失。

分布式

冗余的持久化驅(qū)動我們使用某種分布式策略,至少在磁盤層面上。但是我們還希望通過分布式存儲來提高性能。當(dāng)我們將容器水平擴(kuò)展到成百上千個(gè)節(jié)點(diǎn)上是,我們不希望這些節(jié)點(diǎn)競爭位于同一個(gè)磁盤上的數(shù)據(jù)。所以當(dāng)我們將服務(wù)部署到各個(gè)區(qū)域的環(huán)境上來減少用戶延時(shí)時(shí),我們還希望將存儲也同時(shí)分布式部署。

動態(tài)的

容器架構(gòu)持續(xù)變更。新版本不斷的被構(gòu)建,更新,應(yīng)用被添加或是移除。測試用例被創(chuàng)建并啟動,然后被刪除。在這個(gè)架構(gòu)下,需要能夠動態(tài)的配置和釋放存儲。事實(shí)上,配置存儲應(yīng)當(dāng)和我們聲明容器實(shí)例,服務(wù)和網(wǎng)絡(luò)連通性一樣通過聲明來實(shí)現(xiàn)。

靈活性

容器技術(shù)在飛速發(fā)展,我們需要能夠引入新的存儲策略,并且將應(yīng)用移植到新的存儲架構(gòu)上。我們的存儲策略需要能夠支持任何底層架構(gòu),從開發(fā)人員用于測試的單節(jié)點(diǎn)到一個(gè)開放的云環(huán)境。

透明性

我們需要為各種類型的應(yīng)用提供村塾,而且我們需要持續(xù)更新存儲方案。這意味著我們不應(yīng)該將應(yīng)用強(qiáng)關(guān)聯(lián)與一個(gè)存儲方案。因此,存儲需要看上去像是原生的,也就是對上層用戶來說仿佛是一個(gè)文件系統(tǒng),或者是某種現(xiàn)有的,易于理解的API。

云原生存儲

另一種說法是我們希望容器存儲解決方案是“Cloud Native”(云原生的)。云原生計(jì)算組織(CNCF)定義了云原生系統(tǒng)的三個(gè)屬性。這些屬性也適用于存儲:

容器打包: 我們的物理或虛擬存儲位于容器之外,但是我們希望它僅對特定容器課件(這樣的話,容器就不會共享存儲,除非特殊需求)。除此以外,我們可能希望容器化存儲管理軟件本身,從而利用容器化來管理和升級存儲管理軟件。

動態(tài)管理:對于有狀態(tài)容器的持久部署,我們需要在無需管理員認(rèn)為干預(yù)的情況下,分配存儲給新的容器,并清理失效的存儲。

面向微服務(wù):當(dāng)我們定義一個(gè)容器的時(shí)候,他應(yīng)當(dāng)明確的制定對存儲的依賴。除此以外,存儲管理軟件本身應(yīng)當(dāng)基于微服務(wù)部署,從而更好的實(shí)現(xiàn)擴(kuò)容和異地部署。

提供容器存儲

為了滿足容器持久化存儲的需求,Kubernetes和Docker Swarm提供了一組聲明式資源來聲明并綁定持久化存儲至容器。這些持久化存儲的功能構(gòu)建與一些存儲架構(gòu)之上。我們首先來看一下這兩種環(huán)境下是如何支持容器來聲明對持久化存儲的以來的。

Kubernetes

在Kubernetes中,容器存活于Pods中。每個(gè)pod包含一個(gè)或多個(gè)容器,它們共享網(wǎng)絡(luò)棧和持久存儲。持久化存儲的定義位于pod定義的volumn字段下。該卷可以被掛在到pod的任意一個(gè)容器下。比如,一下有一個(gè)Kubernetes的Pod定義,它使用了一個(gè)emptyDir卷在容器間共享信息。emptyDir卷初始為空,即使pod被遷移到另一個(gè)節(jié)點(diǎn)上仍將保存下來(這意味著容器的崩潰不會使其消失,但是node崩潰會將其刪除)

apiVersion: v1
kind: Pod
metadata:
  name: hello-storage
spec:
  restartPolicy: Never
  volumes:
  - name: shared-data
    emptyDir: {}
  containers:
  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html
  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /pod-data
    command: ["/bin/sh"]
    args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]

如果你將以上內(nèi)容保存到名為two-containers.yaml并使用kubectl create -f two-containers.yaml將其部署到kubernetes上,我們可以使用pod的IP地址來訪問NGINX服務(wù)器,并獲取新建的index.html文件。

這個(gè)例子說明了Kubernetes是如何支持在pod中使用volumn字段聲明一個(gè)存儲依賴的。但是,這不是真正的持久化存儲。如果我們的Kubernetes容器使用AWS EC2,yaml文件如下:

apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: web-files
  volumes:
  - name: web-files
    awsElasticBlockStore:
      volumeID: 
      fsType: ext4

在這個(gè)例子中,我們可以重復(fù)創(chuàng)建和銷毀pod,同一個(gè)持久存儲會被提供給新的pod,無論容器位于哪個(gè)節(jié)點(diǎn)上。但是,這個(gè)例子還是無法提供動態(tài)存儲,因?yàn)槲覀冊趧?chuàng)建pod之前必須先創(chuàng)建好EBS卷。為了從Kubernetes獲得動態(tài)存儲的支持,我們需要另外兩個(gè)重要的概念。第一個(gè)是storageClass,Kubernetes允許我們創(chuàng)建一個(gè)storageClass資源來收集一個(gè)持久化存儲供應(yīng)者的信息。然后將其和persistentVolumeClaim,一個(gè)允許我們從storageClass動態(tài)請求持久化存儲的資源結(jié)合起來。Kubernetes會幫我們向選擇的storageClass發(fā)起請求。這里還是以AWS EBS為例:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: file-store
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  zones: us-east-1d, us-east-1c
  iopsPerGB: "10"
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: web-static-files
spec:
  resources:
    requests:
      storage: 8Gi
  storageClassName: file-store
---
apiVersion: v1
kind: Pod
metadata:
  name: webserver
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: web-files
  volumes:
  - name: web-files
    persistentVolumeClaim:
      claimName: web-static-files

如你所見,我們還在使用volume關(guān)鍵字來制定pod所需要的持久化存儲,但是我們使用了額外的PersistentVolumeClaim聲明來請求Kubernenetes替我們發(fā)起請求。總體上,集群管理員會為每一個(gè)集群部署一個(gè)StorageClass代表可用的底層存儲。然后應(yīng)用開發(fā)者會在第一次需要持久存儲時(shí)指定PersistentVolumeClaim。之后根據(jù)應(yīng)用程序升級的需要部署和更換pod,不會丟失持久存儲中的數(shù)據(jù)。

Docker Swarm

Docker Swarm利用我們在單節(jié)點(diǎn)Docker卷上看到的核心卷管理功能, 從而支持能夠?yàn)槿魏喂?jié)點(diǎn)上的容器提供存儲:

version: "3"
services:
  webserver:
    image: nginx
    volumes:
      - web-files:/usr/share/nginx/html
volumes:
  web-files:
    driver: storageos
    driver-opts:
      size: 20
      storageos.feature.replicas: 2

當(dāng)我們使用docker棧部署時(shí),Docker Swarm會創(chuàng)建web-files卷,仿佛它并不存在。這個(gè)卷會被保留,及時(shí)我們刪除了docker棧。

總的來說,我們可以看到Kubernetes和Docker都滿足了云原生存儲的要求。他們允許容器聲明依賴的存儲,并且動態(tài)的管理存儲從而使其在應(yīng)用需要時(shí)可見。無論容器在集群的哪個(gè)機(jī)器上運(yùn)行,他們都能夠提供持久存儲。

想要了解更多開發(fā)技術(shù),面試教程以及互聯(lián)網(wǎng)公司內(nèi)推,歡迎關(guān)注我的微信公眾號!將會不定期的發(fā)放福利哦~

文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/32738.html

相關(guān)文章

  • 頭鷹深夜翻譯久化容器存儲

    摘要:如果我們的容器使用,文件如下在這個(gè)例子中,我們可以重復(fù)創(chuàng)建和銷毀,同一個(gè)持久存儲會被提供給新的,無論容器位于哪個(gè)節(jié)點(diǎn)上。 前言 臨時(shí)性存儲是容器的一個(gè)很大的買點(diǎn)。根據(jù)一個(gè)鏡像啟動容器,隨意變更,然后停止變更重啟一個(gè)容器。你看,一個(gè)全新的文件系統(tǒng)又誕生了。 在docker的語境下: # docker run -it centos [root@d42876f95c6a /]# echo H...

    tianhang 評論0 收藏0
  • 頭鷹深夜翻譯:你需要了解數(shù)據(jù)庫名詞

    摘要:讀取出數(shù)據(jù)時(shí),將此版本號一同讀出,之后更新時(shí),對此版本號加一。此時(shí),將提交數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)庫表對應(yīng)記錄的當(dāng)前版本信息進(jìn)行比對,如果提交的數(shù)據(jù)版本號大于數(shù)據(jù)庫表當(dāng)前版本號,則予以更新,否則認(rèn)為是過期數(shù)據(jù)。 前言 很多人都在討論數(shù)據(jù)的指數(shù)型增長,以及我們將會有比想象的還要大的數(shù)據(jù)量。但是,很少有人從數(shù)據(jù)庫的角度談?wù)撨@個(gè)問題。隨著數(shù)據(jù)量的暴漲,數(shù)據(jù)庫也需要隨之升級。這也是為什么既要了解如...

    wangym 評論0 收藏0
  • 頭鷹深夜翻譯:分布式系統(tǒng)Toolkit模式

    摘要:根本上來說,這意味著不僅要將整個(gè)應(yīng)用程序分解,而且要將任何一個(gè)服務(wù)器中的各個(gè)部分分解為多個(gè)模塊化容器,這些容器易于參數(shù)化和重復(fù)使用。在中,這種模塊化容器服務(wù)的實(shí)施者是。一個(gè)是指一組共享文件系統(tǒng),內(nèi)核命名空間和地址的一組容器。 過去幾年容器逐漸成為了打包和部署代碼的流行的方式。容器鏡像解決很多現(xiàn)有的打包和部署工具所帶來的問題,初次以外,還為我們提供了構(gòu)建分布式應(yīng)用的全新的思路。就如SOA...

    hiyayiji 評論0 收藏0
  • 頭鷹深夜翻譯:為何需要緩存以及如何實(shí)現(xiàn)緩存

    摘要:由于需要跨進(jìn)程訪問網(wǎng)絡(luò)上的高速緩存,因此延遲,故障和對象序列化會導(dǎo)致性能下降。應(yīng)用程序高速緩存會自動清除條目以保持其內(nèi)存占用。緩存統(tǒng)計(jì)高速緩存統(tǒng)計(jì)信息可幫助識別高速緩存的運(yùn)行狀況并提供有關(guān)高速緩存行為和性能的信息。 前言 這篇文章探索了現(xiàn)有的各種JAVA緩存基數(shù),它們對各種場景下提高應(yīng)用的性能起著重要的作用。 近十年來,信息技術(shù)極高的提升了業(yè)務(wù)流程,它已經(jīng)成為了全球企業(yè)的戰(zhàn)略性方案。它...

    FuisonDesign 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<