2. 程式人生 > >聊聊你可能誤解的Kubernetes Deployment滾動更新機制

聊聊你可能誤解的Kubernetes Deployment滾動更新機制

阿新 • • 發佈：2018-12-23

Author: [email protected]

摘要： Kubernetes Deployment滾動更新機制不同於ReplicationController rolling update，Deployment rollout還提供了滾動進度查詢，滾動歷史記錄，回滾等能力，無疑是使用Kubernetes進行應用滾動釋出的首選。本博文，將帶你聊聊那些容易被大家忽略或者誤解的特性。

定義Deployment時與rolling update的相關項

以下面的frontend Deployment為例，重點關注.spec.minReadySeconds,.spec.strategy.rollingUpdate.maxSurge

,.spec.strategy.rollingUpdate. maxUnavailable。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: frontend
spec:
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 2
  replicas: 25
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google-samples/gb-frontend:v4
        resources:
          requests:
            cpu: 100
 
m
            memory: 100Mi
        env:
        - name: GET_HOSTS_FROM
          value: dns
          # If your cluster config does not include a dns service, then to
          # instead access environment variables to find service host
          # info, comment out the 'value: dns' line above, and uncomment the
          # line below:
          # value
 
: env
        ports:
        - containerPort: 80
  • .spec.minReadySeconds: 新建立的Pod狀態為Ready持續的時間至少為.spec.minReadySeconds才認為Pod Available(Ready)。
  • .spec.strategy.rollingUpdate.maxSurge: specifies the maximum number of Pods that can be created over the desired number of Pods. The value cannot be 0 if MaxUnavailable is 0. 可以為整數或者百分比，預設為desired Pods數的25%. Scale Up新的ReplicaSet時，按照比例計算出允許的MaxSurge，計算時向上取整(比如3.4，取4)。
  • .spec.strategy.rollingUpdate.maxUnavailable: specifies the maximum number of Pods that can be unavailable during the update process. The value cannot be 0 if maxSurge is 0.可以為整數或者百分比，預設為desired Pods數的25%. Scale Down舊的ReplicaSet時，按照比例計算出允許的maxUnavailable，計算時向下取整(比如3.6，取3)。

因此，在Deployment rollout時，需要保證Available(Ready) Pods數不低於 desired pods number - maxUnavailable; 保證所有的Pods數不多於 desired pods number + maxSurge。

滾動更新的流程

Note: A Deployment’s rollout is triggered if and only if the Deployment’s pod template (that is, .spec.template) is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.

我們繼續以上面的Deployment為例子，並考慮最常用的情況–更新image（釋出新版本）:

kubectl set image deploy frontend php-redis=gcr.io/google-samples/gb-frontend:v3 --record

set image之後，導致Deployment’s Pod Template發生變化，就會觸發rollout。我們只考慮RollingUpdate策略（Kubernetes還支援ReCreate更新策略）。通過kubectl get rs -w來watch ReplicaSet的變化。

[root@master03 ~]# kubectl get rs -w
NAME                  DESIRED   CURRENT   READY     AGE
frontend-3114648124   25        25        25        14m
frontend-3099797709   0         0         0         1h
frontend-3099797709   0         0         0         1h
frontend-3099797709   3         0         0         1h
frontend-3114648124   23        25        25        17m
frontend-3099797709   5         0         0         1h
frontend-3114648124   23        25        25        17m
frontend-3114648124   23        23        23        17m
frontend-3099797709   5         0         0         1h
frontend-3099797709   5         3         0         1h
frontend-3099797709   5         5         0         1h
frontend-3099797709   5         5         1         1h
frontend-3114648124   22        23        23        17m
frontend-3099797709   5         5         2         1h
frontend-3114648124   22        23        23        17m
frontend-3114648124   22        22        22        17m
frontend-3099797709   6         5         2         1h
frontend-3114648124   21        22        22        17m
frontend-3099797709   6         5         2         1h
frontend-3114648124   21        22        22        17m
frontend-3099797709   7         5         2         1h
frontend-3099797709   7         6         2         1h
frontend-3114648124   21        21        21        17m
frontend-3099797709   7         6         2         1h
frontend-3099797709   7         7         2         1h
frontend-3099797709   7         7         2         1h
frontend-3099797709   7         7         3         1h
frontend-3099797709   7         7         4         1h
frontend-3114648124   20        21        21        17m
frontend-3099797709   8         7         4         1h
frontend-3114648124   20        21        21        17m
frontend-3114648124   20        20        20        17m
frontend-3099797709   8         7         4         1h
frontend-3099797709   8         8         4         1h
frontend-3099797709   8         8         5         1h
frontend-3114648124   19        20        20        17m
frontend-3099797709   9         8         5         1h
frontend-3114648124   19        20        20        17m
frontend-3099797709   9         8         5         1h
frontend-3099797709   9         9         5         1h
frontend-3114648124   19        19        19        17m
frontend-3099797709   9         9         5         1h
frontend-3114648124   18        19        19        18m
frontend-3099797709   10        9         5         1h
frontend-3114648124   18        19        19        18m
frontend-3099797709   10        9         5         1h
frontend-3114648124   18        18        18        18m
frontend-3099797709   10        10        5         1h
frontend-3099797709   10        10        5         1h
frontend-3114648124   18        18        18        18m
frontend-3099797709   10        10        6         1h
frontend-3099797709   10        10        6         1h
frontend-3114648124   17        18        18        18m
frontend-3114648124   17        18        18        18m
frontend-3099797709   11        10        6         1h
frontend-3099797709   11        10        6         1h
frontend-3114648124   17        17        17        18m
frontend-3099797709   11        11        6         1h

說明：
1. frontend-3114648124為原來的RS（成為OldRS），frontend-3099797709為新建的RS（成為NewRS，當然也可能是Old RS，如果之前執行過這個一樣的內容）。
2. maxSurge:3, maxUnavailable=2, desired replicas=25

  • NewRS建立maxSurge(3)個Pods，這時達到pods數的上限值desired replicas + maxSurge (28個）
  • 不會等NewRS建立的Pods Ready，而是馬上delete OldRS maxUnavailable(2)個Pods，這時Ready的Pods number最差也能保證desired replicas - maxUnavailable(23個)
  • 接下來的流程是不固定，只要新建的Pods有幾個返回Ready，則意味著可以接著刪除幾個舊的Pods了。只要有幾個刪除成功的Pods返回，就會建立一定數量的Pods，只要All pods數量與上限值desired replicas + maxSurge有差值空間，就會接著建立新的Pods。
  • 如此進行滾動更新， 直到建立的新Pods個數達到desired replicas，並等待它們都Ready，然後再刪除所有剩餘的舊的Pods。至此，滾動流程結束。

對同一個Deployment先後觸發滾動更新，邏輯如何？

我們考慮這個情況，但使用者執行某個滾動更新後，未等待此次滾動更新結束，就繼續執行了一次新的滾動更新請求，這時後臺滾動流程會怎麼樣呢？會亂成一鍋粥麼？

我們繼續以這個例子來看：

# deploy frontend 穩定執行在v2(frontend-888714875)時：
[[email protected] ~]# kubectl get rs -w
NAME                DESIRED   CURRENT   READY     AGE

====執行 kubectl set image deploy frontend php-redis=gcr.io/google-samples/gb-frontend:v3 --record
----備註： v3 --> frontend-776431694
frontend-776431694   0         0         0         6h
frontend-776431694   0         0         0         6h
frontend-776431694   3         0         0         6h
frontend-888714875   23        25        25        5h
frontend-776431694   5         0         0         6h
frontend-888714875   23        25        25        5h
frontend-888714875   23        23        23        5h
frontend-776431694   5         0         0         6h
frontend-776431694   5         3         0         6h
frontend-776431694   5         5         0         6h
frontend-776431694   5         5         1         6h
frontend-776431694   5         5         2         6h
frontend-776431694   5         5         3         6h
frontend-776431694   5         5         4         6h
frontend-776431694   5         5         4         6h
frontend-888714875   22        23        23        5h
frontend-776431694   6         5         4         6h
frontend-888714875   22        23        23        5h
frontend-888714875   22        22        22        5h
frontend-776431694   6         5         4         6h
frontend-776431694   6         6         4         6h
frontend-776431694   6         6         4         6h
frontend-888714875   19        22        22        5h
frontend-776431694   9         6         4         6h
frontend-888714875   19        22        22        5h
frontend-776431694   9         6         4         6h
frontend-888714875   19        19        19        5h
frontend-776431694   9         9         4         6h
frontend-888714875   19        19        19        5h

==== 執行 kubectl set image deploy frontend php-redis=gcr.io/google-samples/gb-frontend:v4 --record ====
----- 備註：v4 --> frontend-3099797709 ----

frontend-3099797709   0         0         0         6h
frontend-3099797709   0         0         0         6h
frontend-776431694   4         9         4         6h
frontend-3099797709   5         0         0         6h
frontend-3099797709   5         0         0         6h
frontend-3099797709   5         5         0         6h
frontend-776431694   4         9         4         6h
frontend-776431694   4         4         4         6h
frontend-3099797709   5         5         0         6h
frontend-3099797709   5         5         1         6h
frontend-3099797709   5         5         2         6h
frontend-3099797709   5         5         3         6h
frontend-3099797709   5         5         4         6h
frontend-3099797709   5         5         4         6h
frontend-776431694   2         4         4         6h
frontend-3099797709   7         5         4         6h
frontend-776431694   2         4         4         6h
frontend-776431694   2         2         2         6h
frontend-776431694   2         2         2         6h
frontend-3099797709   7         5         4         6h
frontend-776431694   0         2         2         6h
frontend-3099797709   7         7         4         6h
frontend-776431694   0         2         2         6h
frontend-3099797709   9         7         4         6h
frontend-776431694   0         0         0         6h
frontend-3099797709   9         7         4         6h
frontend-3099797709   9         9         4         6h
frontend-776431694   0         0         0         6h
frontend-3099797709   9         9         4         6h
frontend-3099797709   9         9         5         6h
frontend-3099797709   9         9         6         6h
frontend-3099797709   9         9         7         6h
frontend-888714875   17        19        19        5h
frontend-3099797709   11        9         7         6h
frontend-888714875   17        19        19        5h
frontend-888714875   17        17        17        5h
frontend-3099797709   11        9         7         6h
frontend-888714875   16        17        17        5h
frontend-3099797709   11        11        7         6h
frontend-3099797709   12        11        7         6h
frontend-888714875   16        17        17        5h
frontend-888714875   16        16        16        5h
frontend-3099797709   12        11        7         6h
frontend-3099797709   12        12        7         6h
frontend-3099797709   12        12        8         6h
frontend-3099797709   12        12        8         6h
frontend-888714875   15        16        16        5h
frontend-3099797709   13        12        8         6h
frontend-888714875   15        16        16        5h
frontend-888714875   15        15        15        5h
frontend-3099797709   13        12        8         6h
frontend-3099797709   13        13        8         6h
frontend-3099797709   13        13        8         6h
frontend-3099797709   13        13        9         6h
frontend-3099797709   13        13        10        6h
frontend-888714875   14        15        15        5h
frontend-3099797709   14        13        10        6h
frontend-888714875   14        15        15        5h
frontend-888714875   14        14        14        5h
frontend-3099797709   14        13        10        6h
frontend-888714875   14        14        14        5h
frontend-3099797709   14        14        11        6h
frontend-3099797709   14        14        12        6h
frontend-3099797709   14        14        12        6h
frontend-3099797709   14        14        12        6h
frontend-888714875   11        14        14        5h
frontend-3099797709   17        14        12        6h
frontend-888714875   11        14        14        5h
frontend-3099797709   17        14        12        6h
frontend-888714875   11        11        11        5h
frontend-3099797709   17        17        12        6h
frontend-888714875   11        11        11        5h
frontend-3099797709   17        17        12        6h
frontend-3099797709   17        17        13        6h
frontend-3099797709   17        17        14        6h
frontend-3099797709   17        17        14        6h
frontend-888714875   10        11        11        5h
frontend-3099797709   18        17        14        6h
frontend-888714875   10        11        11        5h
frontend-888714875   10        10        10        5h
frontend-3099797709   18        17        14        6h
frontend-3099797709   18        18        14        6h
frontend-3099797709   18        18        15        6h
frontend-888714875   9         10        10        5h
frontend-3099797709   18        18        16        6h
frontend-888714875   9         10        10        5h
frontend-3099797709   19        18        16        6h
frontend-3099797709   19        18        16        6h
frontend-888714875   9         9         9         5h
frontend-888714875   7         9         9         5h
frontend-3099797709   19        18        16        6h
frontend-888714875   7         9         9         5h
frontend-3099797709   21        18        16        6h
frontend-888714875   7         9         9         5h
frontend-3099797709   21        19        16        6h
frontend-888714875   7         7         7         5h
frontend-3099797709   21        21        16        6h
frontend-888714875   7         7         7         5h
frontend-3099797709   21        21        17        6h
frontend-3099797709   21        21        18        6h
frontend-3099797709   21        21        18        6h
frontend-888714875   5         7         7         5h
frontend-888714875   5         7         7         5h
frontend-3099797709   23        21        18        6h
frontend-888714875   5         5         5         5h
frontend-3099797709   23        21        18        6h
frontend-3099797709   23        23        18        6h
frontend-3099797709   23        23        18        6h
frontend-3099797709   23        23        19        6h
frontend-3099797709   23        23        20        6h
frontend-3099797709   23        23        20        6h
frontend-888714875   3         5         5         5h
frontend-3099797709   25        23        20        6h
frontend-888714875   3         5         5         5h
frontend-888714875   3         3         3         5h
frontend-3099797709   25        23        20        6h
frontend-888714875   3         3         3         5h
frontend-3099797709   25        25        20        6h
frontend-3099797709   25        25        21        6h
frontend-3099797709   25        25        22        6h
frontend-3099797709   25        25        22        6h
frontend-888714875   2         3         3         5h
frontend-888714875   2         3         3         5h
frontend-888714875   2         2         2         5h
frontend-888714875   2         2         2         5h
frontend-3099797709   25        25        23        6h
frontend-888714875   1         2         2         5h
frontend-888714875   1         2         2         5h
frontend-888714875   1         1         1         5h
frontend-3099797709   25        25        23        6h
frontend-888714875   0         1         1         5h
frontend-888714875   0         1         1         5h
frontend-888714875   0         0         0         5h
frontend-3099797709   25        25        24        6h
frontend-3099797709   25        25        25        6h
frontend-3099797709   25        25        25        6h

說明：
deployment frontend穩定執行在v2版本(RS：frontend-888714875)，然後執行kubectl set image觸發滾動更新到v3版本（RS: frontend-776431694）, 當v3 RS的desired個數scale up到9個，ready個數為4個時，使用者又執行kubectl set image觸發滾動更新到v4版本（RS: frontend-3099797709）。

說明，我自己是這樣玩的，先建立的v4 RS，然後v3 RS，然後v2 RS。因此按照建立時間從新到舊排序RS為，v2–>v3–>v4。

  • v2到v3的滾動流程同上一小節的描述；
  • 當新的滾動流程觸發後，按照RS建立時間排序，最新（除v4外）的v2的RS保持不動，不會繼續scale down。
  • 然後v4將通過滾動更新的方式把已經scale up的9個最老的v3 RS的pods替換掉，將所有v3的Pods升級到v4。
  • 最後再接著v4 RS滾動更新把v2的RS所有的舊Pods都升級到v4。
  • 整個完整的滾動流程中，都必須遵守maxSurge和maxUnavailable的約束，不能越雷池半步。

設想一個更復雜的場景：如果在上述v4滾動更新替換到半吊子的v3 RS過程中，使用者又觸發了一個滾動更新到v5版本，流程會怎麼樣呢？
不要怕，原理是一樣的，Deployment rolling update總是先把最老的RS滾動更新替換掉，然後逐步把新的RS滾動更新替換掉，直到最最新的那個RS scale down為0，流程就結束了。

理解rollout pause和resume

或許很多人至今還會這麼覺得：整個滾動更新的過程中，一旦使用者執行了kubectl rollout pause deploy/frontend後，正在執行的滾動流程就會立刻停止，然後使用者執行kubectl rollout resume deploy/frontend就會繼續未完成的滾動更新。那你就大錯特錯了！

kubectl rollout pause只會用來停止觸發下一次rollout。什麼意思呢？ 上面描述的這個場景，正在執行的滾動歷程是不會停下來的，而是會繼續正常的進行滾動，直到完成。等下一次，使用者再次觸發rollout時，Deployment就不會真的去啟動執行滾動更新了，而是等待使用者執行了kubectl rollout resume，流程才會真正啟動執行。

ReplicaSet和rollout history的關係

前提，你要知道關於--record：
Setting the kubectl flag –record to true allows you to record current command in the annotations of the resources being created or updated.

預設情況下，所有通過kubectl xxxx –record都會被kubernetes記錄到etcd進行持久化，這無疑會佔用資源，最重要的是，時間久了，當你kubectl get rs時，會有成百上千的垃圾RS返回給你，那時你可能就眼花繚亂了。

上生產時，我們最好通過設定Deployment的.spec.revisionHistoryLimit來限制最大保留的revision number，比如15個版本，回滾的時候一般只會回滾到最近的幾個版本就足夠了。

執行下面的命令，可以返回某個Deployment的所有record記錄：

$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment"
REVISION    CHANGE-CAUSE
1           kubectl create -f docs/user-guide/nginx-deployment.yaml --record
2           kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
3           kubectl set image deployment/nginx-deployment nginx=nginx:1.91

然後執行rollout undo命令就可以回滾到to-revision指定的版本。

kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back

其實rollout history中記錄的revision都和ReplicaSets一一對應。如果手動delete某個ReplicaSet，對應的rollout history就會被刪除，也就是還說你無法回滾到這個revison了。

roolout history和ReplicaSet的對應關係，可以在kubectl describe rs $RSNAME返回的revision欄位中得到，這裡的revision就對應著roolout history返回的revison。

回滾是如何進行的

使用者通過執行rollout undo並指定--to-revison，可以將Deployment回滾到指定的revision。

kubectl rollout undo deploy frontend --to-revision=7

通過觀察後端RS的資料變化，同樣發現，回滾的時候也是按照滾動的機制進行的，同樣要遵守maxSurge和maxUnavailable的約束。並不是一次性將所有的Pods刪除，然後再一次性建立新的Pods。

[root@master01 ~]# kubectl get rs -w
NAME                   DESIRED   CURRENT   READY     AGE
frontend-888714875   3         0         0         23h
frontend-776431694   8         10        10        23h
frontend-888714875   5         0         0         23h
frontend-776431694   8         10        10        23h
frontend-776431694   8         8         8         23h
frontend-888714875   5         0         0         23h
frontend-888714875   5         3         0         23h
frontend-888714875   5         5         0         23h
frontend-888714875   5         5         1         23h
frontend-888714875   5         5         2         23h
frontend-888714875   5         5         4         23h
frontend-776431694   6         8         8         23h
frontend-888714875   5         5         4         23h
frontend-888714875   5         5         5         23h
frontend-776431694   6         8         8         23h
frontend-888714875   7         5         5         23h
frontend-776431694   6         6         6         23h
frontend-776431694   3         6         6         23h
frontend-888714875   10        5         5         23h
frontend-776431694   3         6         6         23h
frontend-776431694   3         3         3         23h
frontend-888714875   10        5         5         23h
frontend-776431694   3         3         3         23h
frontend-888714875   10        7         5         23h
frontend-888714875   10        10        5         23h
frontend-888714875   10        10        6         23h
frontend-888714875   10        10        7         23h
frontend-888714875   10        10        8         23h
frontend-888714875   10        10        8         23h
frontend-888714875   10        10        9         23h
frontend-888714875   10        10        9         23h
frontend-888714875   10        10        9         23h
frontend-776431694   0         3         3         23h
frontend-776431694   0         3         3         23h
frontend-776431694   0         0         0         23h
frontend-888714875   10        10        10        23h
frontend-888714875   10        10        10        23h

總結

本博文介紹了關於Deployment rolling update那些容易被大家忽略或者誤解的特性，如果看完這篇博文，你覺得“我去! 本來就是這樣子的啊！”，那說明你對Deployment Controller非常熟悉。

  • 介紹了Deployment時與rolling update的相關項；
  • 說明了滾動更新的流程；
  • 介紹了對同一個Deployment先後觸發滾動更新，邏輯如何？
  • 正確理解rollout pause和resume
  • 明白ReplicaSet和rollout history的內在關係
  • 回滾的機制同滾動更新。

相關推薦

聊聊你可能誤解的Kubernetes Deployment滾動更新機制

Author: [email protected] 摘要： Kubernetes Deployment滾動更新機制不同於ReplicationController rolling update，Deployment rollout還提供了滾

Kubernetes Deployment滾動更新場景分析

基於Kubernetes v1.7.4 關於Kubernetes Deployment滾動更新 場景1：正常滾動更新流程 新建deployment：webserver，replicas=10，image=tomcat。 滾動更新

Kubernetes Service滾動更新

cond 發出 point rpo use 應用 一次 歷史 針對 [toc] 簡介 滾動更新 當kubernetes集群中的某個服務需要升級時，傳統的做法是，先將要更新的服務下線，業務停止後再更新版本和配置，然後重新啟動並提供服務。如果業務集群規模較大時，這個工作就變成了

Cookie的優先順序，你可能誤解的

關鍵字：Cookie，優先順序（Precedence, Priority） 問題 Server端分別在不同的域（domain）或者不同的路徑（Path）添加了名字相同的Cookie，比如： Cookie名 域名 Path 值 tokenId mydomain.com / r

Log4j2中RollingFile的檔案滾動更新機制 一、什麼是RollingFile RollingFileAppender是Log4j2中的一種能夠實現日誌檔案滾動更新(rollover)的

一、什麼是RollingFile RollingFileAppender是Log4j2中的一種能夠實現日誌檔案滾動更新(rollover)的Appender。 rollover的意思是當滿足一定條件(如檔案達到了指定的大小，達到了指定的時間)後，就重新命名原日誌檔案進行歸檔，並生成新的日誌檔案用於log寫入

詳細聊聊k8s deployment的滾動更新（二）

roo 10.10 metadata 系統 lifecycle aliyun container head 能夠 原文:詳細聊聊k8s deployment的滾動更新（二） 一、知識準備 ● 本文詳細探索deployment在滾動更新時候的行為 ● 相關的參數介紹

Kubernetes——自動擴展容器！假設你突然需要增加你的應用;你只需要告訴deployment一個新的 pod 副本總數即可

運行 class 都在 功能 ima curl docs extern read 參考：http://kubernetes.kansea.com/docs/hellonode/ 現在你應該可以通過這個地址來訪問這個service: http://EXTERNAL_IP:

kubernetes 滾動更新發布及回滾

bsp uber record kubectl 滾動 app 記錄 post 回滾 基本命令 記錄歷史 --record kubectl apply -f **** --record 查看當前狀態 kubectl rollout status deployment/dem

Kubernetes集群中Service的滾動更新

k8s config level apiserver div restfu ceph 成功 lac Kubernetes集群中Service的滾動更新 二月 9, 2017 0 條評論 在移動互聯網時代，消費者的消費行為已經“全天候化”，為此，商家的業務系統也要保持7

kubernetes 滾動更新

set grace ini 版本 mina desc mman exp pau 示例： 創建一個app：kubectl create deployment nginx --image=nginx:1.11 創建service kubectl expose deploy

Kubernetes Pod應用的滾動更新(八)

一、環境準備 我們緊接上一節的環境，進行下面的操作，如果不清楚的，可以先檢視上一篇博文。 滾動更新是一次只更新一小部分副本，成功後，再更新更多的副本，最終完成所有副本的更新。滾動更新的最大的好處是零停機，整個更新過程始終有副本在執行，從而保證了業務的連續性。 二、更新 我們檢視一下上一節的配置檔案my

Kubernetes滾動更新介紹及使用

我們 k8s叢集使用的是1.7.7版本的，該版本中官方已經推薦使用 Deployment代替 ReplicationController(rc)了， Deployment繼承了rc的全部功能外，還可以檢視升級詳細進度和狀態，當升級出現問題的時候，可以使用回滾操作回滾到指

12月12日雲棲精選夜讀 | Python 10大謬論，你可能對Python存在的一些誤解！

謬誤 #1: Python 是一門新語言 伴隨著所有的初創公司正在使用它以及孩子們最近也在學習它的事實，這個謬誤為何仍然存在是可以理解的。實際上 Python 已經 超過23歲了, 它最初發佈於1991年, 早於 HTTP  熱點熱議 Python 10大謬論，你可能對Python存在的一些

kubernetes學習(一) Scale應用 & 滾動更新

一、Scale應用 　　預設請款下應用只會執行一個副本，可通過kubectl get deployments 檢視副本數。 ~$ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILA

kubernetes DaemonSet的滾動更新

DaemonSet的滾動更新 DaemonSet 更新策略 DaemonSet 有兩種更新策略 : OnDelete: 預設的向後相容更新策略. 只有當你手動刪除老的DaemonSet pods

windows XP更新後出現“你可能是盜版軟體受害者”解決方法

現在的D版事業真是猖盛，微軟才出沒多久的正版檢驗程式補丁，已經有了破解的辦法了。廣大D版使用者有福了:->。 windows XP更新時，如果更新了Windows Genuine Advantage Notification KB905474補丁，系統裡會被植入一個名為

Node.js的Buffer那些你可能不知道的用法

ins min 來看 imu write work and sse ase 在大多數介紹Buffer的文章中，主要是圍繞數據拼接和內存分配這兩方面的。比如我們使用fs模塊來讀取文件內容的時候，返回的就是一個Buffer： fs.readFile(‘filename‘, fu

未來，你可能不屬於任何公司

交易 成了 data 而是 三分 ron 動向 image 參考 優步自己沒有車，只是用車平臺；阿裏自己沒有貨，只是交易平臺；微博自己不生產內容，只是內容平臺…… 那麽人才呢？是否也沒必要用企業的形式組織起來，而用平臺的方式呢？ 實際上，追溯回去的話，“企業”這種組織

張書樂：在發爾康和葛優躺表情包時，你可能在侵權，他卻在賺錢

表情包使用次數TOP10的表情符號裏，“哭笑不得”的表情使用次數最多，總計高達7518440701次；女性青年每人平均每天使用表情2.84次，而男性青年每人平均每天使用表情次數為0.74次，女性是男性的3.83倍。與男性相比，女性的表情使用普遍偏感性。文/張書樂（人民網、人民郵電報專欄作者）新著有《微博運營完

Vue 實際項目中你可能會遇見的坑

只需要 lint .com tro 生產 首次加載 int on() 格式 　　紙上得來終覺淺，絕知此事要躬行！ 　　Vue的文檔和教程看的太多，小的demo做的多，也不如自己實際的進行一個完整項目的開發。只有做了才知道原來問題這麽多，這裏列舉了一些你做demo教程可能不會