快速理解基本的容器开发，独自学习Kubernetes

1 年 ago

新, 韵

10 minutes

首先

这篇文章是为了帮助即将开始学习Kubernetes的人而写的，目的是为了尽快理解容器开发的基础知识而提供的入门文章。

尽管称为入门文章，但我们假设读者已经有对于容器虚拟化技术的抽象概念理解作为基础知识，并且在稍微深入探讨的同时，旨在提供关于Kubernetes的引入、基本操作以及相关技术的理解。

前提知識 tí zhī shí)

在开始学习Kubernetes之前，需要了解容器虚拟化技术的知识。本文将使用Docker作为容器虚拟化技术的例子，但基本的Docker知识将会被省略。以下是需要掌握的知识。

Docker Hub

关于容器虚拟化技术，稍微深入一点。

使用容器化技术可以通过操作系统内核的功能来实现。利用操作系统内核的功能，将主机资源隔离并分配给每个容器，从而创建独立的空间。同时，为了实现这种独立的空间，提供了一个软件解决方案，即LXC。

LXC 是 Linux 内核为容器功能提供的用户空间接口。 Docker 和 LXC 可以混合使用，但它们分别属于不同的软件。 Docker 旨在用于应用程序部署，因此它提倡”每个容器一个进程”的理念，而 LXC 被称为”操作系统级虚拟化软件”。 Docker 到版本 0.8 也是使用了 LXC。

目前，Docker架构被分成了四个组件：Docker引擎、containerd、containerd-shm和runC。它们的二进制文件分别被称为docker、docker-containerd、docker-containerd-shim和docker-runc。

为了运行容器，Docker Engine会创建镜像并将其传递给containerd。containerd会调用containerd-shim来使用runC运行容器。然后，containerd-shim会确保在容器启动后可以终止运行时（在此示例中为runC）。这样做是为了避免需要为容器持续运行的长时间运行时进程，从而可以运行无守护进程的容器。

运行时间

运行时（runtime）指的是程序执行时以及执行时所需的物品。让我们稍微了解一下容器运行时（container runtime）。

容器管理守护进程

containerd负责管理运行的容器。

containerdはもともとDocker社によって開発されてきましたが、標準的なランタイム実装を実現するために、Docker社から中立的な団体であるCloud Native Computing Foundationに（CNCF）に、2017年3月に寄贈されました。

容器监控服务-Shim

containerd-shimは、デーモンレスコンテナを可能にします。
起動されたすべてのコンテナの親プロセスであり、デーモンなしのコンテナも許可されます。

运行

runC是一个用于创建和启动容器的二进制程序。此外，runC是基于与Docker Engine相同的技术libcontainer实现的。

Docker社によって開発され、オープンソース化されていますが、現在はコンテナ型仮想化技術の標準化に取り組むOpen Container Initiative（OCI）（※1）が定義する仕様で、事実上コンテナ型仮想化技術のデファクトスタンダードとなっています。実装としては、Namespace、cgroups、pivot_root、AppArmor、SELinux、seccomp等により、セキュア（※2）なコンテナを作り出しています。

（※1）开放容器倡议（OCI）的目标是在容器生态系统中建立软件容器的共同标准，以避免潜在的碎片化和分割，并包含了两项指标。

image-spec：イメージ仕様

（※2）2019年2月12日に、runcの脆弱性（CVE-2019-5736）が発見されています。この脆弱性により、悪意のあるコンテナが（最小限のユーザーで）許可されます。ホストのruncバイナリを上書きして、rootレベルになるホスト上で任意のコマンドを実行することができるようになります。

docker info | grep ‘Runtime’

容器技术

libcontainer是一个用Go语言实现的库。

Docker的容器功能在0.8版本之前依赖于LXC，但从0.9版本开始改为直接调用内核的容器API的libcontainer驱动程序。

内核 hé)

内核是操作系统（OS）的核心部分。
它将CPU、内存、设备输入输出等硬件资源进行抽象化。

コンテナ型仮想化技術は、ホスト型やハイパーバイザー型等他の仮想化技術に比べて、オーバーヘッドが少ないため、軽量で高速に動作するのが特徴です。

文件系统

Dockerでは、複数のファイルシステム上のディレクトリやファイルをレイヤとして重ね合わせ、それらを仮想的に一つのファイルシステムとして扱うことにより、イメージを実現しています。また、イメージレイヤに対するコンテナ上でのファイルの更新は、コピーオンライトによって実現しています。コピーオンライト処理は、ストレージドライバによって実装が異なります。

例として、Aufsは、複数の異なるファイルシステム (ブランチと呼ばれる) のファイルやディレクトリ同士を透過的に重ねる (マージする) ことができる技術です。

docker history イメージ

命名空间

Namespaceは、コンテナ毎に異なる論理的な空間を提供し、隔離するための技術です。

名前空間定数概要IPCCLONE_NEWIPCSystem V プロセス間通信オブジェクトと呼ばれる、POSIXメッセージキュー等内部のプロセス間通信を分離する。MOUNTCLONE_NEWNSNamespace内に隔離されたファイルシステムツリーを作り、ファイルシステムツリーを分離する。NetworkCLONE_NEWNETネットワークデバイス、IPアドレス、ポート番号、ルーティングテーブル、フィルタリングテーブル等ネットワークリソースを分離するPID　CLONE_NEWPIDPID(プロセスID)を分離する。UIDCLONE_NEWUSERUIDやGIDを分離する。UTSCLONE_NEWUTSuname() システムコールから返される2つのシステム識別子(ホスト名やNISドメイン名)を分離する。

控制组

cgroupsは、プロセスグループのリソース(CPU、メモリ、ディスクI/O等)の利用を制限・隔離するLinuxカーネルの機能です。グループ内のプロセスから他のグループのリソースが見えないようにできているのは、名前空間による隔離機能が働いているためです。

興味があれば、カーネルソースのtask_struct()を見てみるといいかもしれません。

Linux内核中，进程以名为task_struct的相当庞大的数据结构表示。task_struct可以在./linux/include/linux/sched.h中找到。

chroot – 更改根目录

Chroot是一项古老的技术，但为了更好地理解虚拟化技术，知道它是很好的选择。

chrootは、ファイルシステムの名前空間を隔離します。もう少し分かりやすく言うと、これ以上のディレクトリに行かせないように、ルートディレクトリを変更します。但し、隔離するのは、あくまでファイルシステムのみです。他のリソースは隔離しないため、ユーザーIDやネットワークインターフェイスは共通のものが見えます。

身近な例としては、bindの構築で使用されています。chrootすることで、/var/named/chrootがルートディレクトリになり、bindプロセスがアクセス可能な範囲を制限することを目的としています。これにより、万が一攻撃を受けて侵入されても、/var/namedディレクトリだけが影響を受けます。

chrootを使用する場合は、どこを起点にしているかで相対的位置を理解しておくと、トラブルの防止になります。

Kubernetes简介

Kubernetes是一种容器编排工具，它允许声明式配置和容器自动操作。作为一个分布式系统，它提供API以实现可靠性、可用性和可扩展性。

谷歌（Google）在2014年开发的Kubernetes，在2017年10月的DockerCon EU上宣布与Docker集成后，整个环境发生了巨大变化。目前，它已得到主要云服务提供商的支持，作为容器编排工具的重要性依然不变。

CEK（Container Engine for Kubernetes）（※3）

（※1）Googleが社内のアプリケーション基盤として利用していた「Borg」と呼ばれるシステムが元
（※2）ACS（Azure Container Service）のサポートは2020年1月31日をもって終了
（※3）Oracleが提供するクラウドサービス

音樂配器樂器

オンプレミスにおけるシステムの拡張方式は、スケールアップやスケールアウトの運用が一般的でしたが、クラウドの登場により、必要なときに、必要なリソースを迅速に構築する仕組みとしてオーケストレーションツールが生まれました。コンテナに係るオーケストレーションツールとして、主要なクラウドサービス以外でも以下のような種類があります。

開発元　サービスRed HatOpenShiftPivotalPKSDockerSwarmApacheApache MesosRancher LabsRancherMesosphereMesosphere DC/OSCloud FoundryCFCR（Cloud Foundry Container Runtime）

オーケストレーションツールは、Kubernetesのシェアが高いですが、Googleがオープンソース化したgVisor、OpenStack Foundationが開発したKata Containers、Kubernetesにネイティブ対応したコアランタイムのcontainerd等多様なランタイムが登場すると見込まれており、コンテナ型仮想化技術の動向踏まえて、今後も目が離せません。

建筑设计

Deploymentを1つの単位として、アプリケーションをデプロイする

Kubernetes的组件

我们在Master上接收API，进行Node的管理和Kubernetes集群的控制。通过Node中的kubelete来管理Pod内的容器。此外，通过仪表板和DNS等插件，作为Kubernetes集群的功能。

请参阅Kubernetes组件以详细了解Kubernetes的组件。

容器运行时接口

Kubernetes和Docker之间通过Kubernetes标准化的CRI（容器运行时接口）进行交互。以下是关于Kubernetes中容器运行时接口（CRI）的介绍的博客文章。

在Kubernetes中引入容器运行时接口（CRI）。

关于Kubernetes和CRI的兼容性问题，请参考GitHub上containerd/cri存储库的README文件。

Kubernetes的意义

让我们了解Kubernetes的重要性。
可以通过了解Borg、Omega和Kubernetes的历史来了解Borg的背景。

其他

以下是与Kubernetes相关的工具和框架等的详细描述。

Anthosは、Kubernetesをベースにアプリケーションのマルチクラウド対応を実現する新サービスです。Google Cloud上ではGoogle Kubernetes Engine（GKE）上で稼働し、オンプレミスではGKE on Prem上で稼働。さらにAWS上でも稼働予定のため、Google以外のクラウドサポートが見込まれています。また、オンプレミスでのAnthosの実行環境は、現時点ではGKE on premの稼働条件であるVMware 6.5以上、F5 BIG-IPとされています。

安装Kubernetes

让我们在本地环境中安装和使用Kubernetes。

本文的环境如下所示。

设备：iMac
先决条件：已安装Docker Desktop for Mac

使用Kubernetes的操作

Kubernetes可以通过命令行和图形界面进行操作。

kubectl 命令

kubectl是用于在命令行中操作Kubernetes的工具。kubectl的概述（包括命令的语法等）详见kubectl的概述。

检查Kubernetes集群的状态

以下是用于检查Kubernetes集群状态的命令。

kubectl version

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:38:32Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:25:46Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

kubectl get componentstatus

NAME                 STATUS    MESSAGE              ERROR
controller-manager   Healthy   ok                   
scheduler            Healthy   ok                   
etcd-0               Healthy   {"health": "true"}

kubectl get nodes

NAME                 STATUS    ROLES     AGE       VERSION
docker-for-desktop   Ready     master    59d       v1.10.11

kubectl describe nodes ノード名

仪表盘 (yí

通过使用仪表板，您可以从浏览器管理Kubernetes集群。

以下のコマンドを実行し、ダッシュボードを追加します。

使用以下命令在本地安装Kubernetes控制台：kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.8.3/src/deploy/recommended/kubernetes-dashboard.yaml

secret "kubernetes-dashboard-certs" created
serviceaccount "kubernetes-dashboard" created
role.rbac.authorization.k8s.io "kubernetes-dashboard-minimal" created
rolebinding.rbac.authorization.k8s.io "kubernetes-dashboard-minimal" created
deployment.apps "kubernetes-dashboard" created
service "kubernetes-dashboard" created

执行以下命令以确认已部署成功。

获取带有 k8s-app=kubernetes-dashboard 标签的 Kubernetes 仪表盘 Pod，在 kube-system 命名空间中。

NAME                                    READY     STATUS    RESTARTS   AGE
kubernetes-dashboard-7d5dcdb6d9-6tpxv   1/1       Running   0          1m

执行以下命令，启动代理服务器并连接到仪表板。

kubectl代理

Starting to serve on 127.0.0.1:8001

从浏览器上访问仪表板时，会显示如下界面，点击”跳过”。

当你在实际运用中使用时，使用认证功能在安全性上更为理想。

会展示仪表盘。

获取令牌的方式

在登录仪表板时，您可以通过指定令牌进行登录。以下是具体方法：

执行以下命令，确定默认令牌。

kubectl -n kube-system get secret | grep default-token的中文原生释义是：在kube-system命名空间中获取密钥并使用grep过滤出default-token。

default-token-fx2v4                              kubernetes.io/service-account-token   3         52d

执行以下命令，输出token的内容。

查看kube-system命名空间下default-token-fx2v4的密钥的详细信息。

Name:         default-token-fx2v4
Namespace:    kube-system
Labels:       <none>
Annotations:  kubernetes.io/service-account.name=default
              kubernetes.io/service-account.uid=d9b76415-3c80-11e9-9164-025000000001

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1025 bytes
namespace:  11 bytes
token:      （※）トークンの内容が出力される

在登录仪表板时，通过指定令牌，在上述命令输出结果中输入令牌即可完成登录。

Kubernetes API 对象

所有在Kubernetes上的资源都以RESTful资源（Kubernetes对象）来表示。

举个例子，Kubernetes Deployment 是一个能够表示在 Kubernetes 集群上运行的应用程序的对象。为了操作 Kubernetes 对象，我们使用 Kubernetes API。

Kubernetes的API对象可以用YAML或JSON表示。您可以使用YAML或JSON文件通过API进行对象的创建、更新、删除等操作。

Pod: 豆荚

Pod是Kubernetes集群中的最小部署单元。Pod中的应用程序使用相同的IP地址和端口。Pod的配置在Pod清单中进行记录。

Pod清单可以用YAML或JSON编写。通常情况下，使用YAML编写的方式更常见。通过使用缩进来表示数据的层级结构，YAML非常易于阅读和编写，但也是部署时出现错误的原因之一。

在Chinese（中文）中有多种方式可以对以下进行表达，这里提供一种选项：
Kubernetes YAML格式的编写方法请参考Understanding Kubernetes Objects。

播客操作

以下是执行基本Pod操作的命令，以kuard为例。

在kubectl命令的参数中，可以使用”pod”或”pods”来指定资源类型，也可以缩写为”po”来指定。

kuard-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  containers:
    - name: kuard
      image: gcr.io/kuar-demo/kuard-amd64:1
      ports:
        - containerPort: 8080
          name: echo
          protocol: TCP

kubectl apply -f kuard-pod.yaml

pod "kuard" created

kubectl get pod

NAME                READY     STATUS    RESTARTS   AGE
kuard               1/1       Running   0          5s

kubectl describe pod kuard

Name:         kuard
Namespace:    default
Node:         docker-for-desktop/192.168.65.3
Start Time:   Sun, 21 Apr 2019 20:41:37 +0900
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"kuard","namespace":"default"},"spec":{"containers":[{"image":"gcr.io/kuar-demo/kua...
Status:       Running
IP:           10.1.0.65
Containers:
  kuard:
    Container ID:   docker://c5440df7d9eec2b10aa77baf29fe690597a98d68681d4ea49d1ee075745d5f78
    Image:          gcr.io/kuar-demo/kuard-amd64:1
    Image ID:       docker-pullable://gcr.io/kuar-demo/kuard-amd64@sha256:bd17153e9a3319f401acc7a27759243f37d422c06cbbf01cb3e1f54bbbfe14f4
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 21 Apr 2019 20:41:39 +0900
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-vgzn7 (ro)
Conditions:
  Type           Status
  Initialized    True 
  Ready          True 
  PodScheduled   True 
Volumes:
  default-token-vgzn7:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-vgzn7
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason                 Age   From                         Message
  ----    ------                 ----  ----                         -------
  Normal  Scheduled              41s   default-scheduler            Successfully assigned kuard to docker-for-desktop
  Normal  SuccessfulMountVolume  41s   kubelet, docker-for-desktop  MountVolume.SetUp succeeded for volume "default-token-vgzn7"
  Normal  Pulled                 40s   kubelet, docker-for-desktop  Container image "gcr.io/kuar-demo/kuard-amd64:1" already present on machine
  Normal  Created                39s   kubelet, docker-for-desktop  Created container
  Normal  Started                39s   kubelet, docker-for-desktop  Started container

kubectl delete -f kuard-pod.yaml

pod "kuard" deleted

kubectl logs kuard

2019/04/23 09:10:58 Starting kuard version: v0.8.1-1
2019/04/23 09:10:58 **********************************************************************
2019/04/23 09:10:58 * WARNING: This server may expose sensitive
2019/04/23 09:10:58 * and secret information. Be careful.
2019/04/23 09:10:58 **********************************************************************
2019/04/23 09:10:58 Config: 
{
  "address": ":8080",
  "debug": false,
  "debug-sitedata-dir": "./sitedata",
  "keygen": {
    "enable": false,
    "exit-code": 0,
    "exit-on-complete": false,
    "memq-queue": "",
    "memq-server": "",
    "num-to-gen": 0,
    "time-to-run": 0
  },
  "liveness": {
    "fail-next": 0
  },
  "readiness": {
    "fail-next": 0
  },
  "tls-address": ":8443",
  "tls-dir": "/tls"
}
2019/04/23 09:10:58 Could not find certificates to serve TLS
2019/04/23 09:10:58 Serving on HTTP on :8080

kubectl port-forward kuard 8080:8080

复制集

“レプリカ”という言葉は、複製を指す意味です。
在Kubernetes集群中，ReplicaSet会复制Pod。
根据ReplicaSet清单文件中定义的replicas值，进行Pod的复制。

(※)既にPodが起動していて、不足していればその分Podを複製します。多い場合にReplicaSetマニフェストを適用すると、その分削除されます。

复制集操作

kuardを例に、基本的なReplicaSet操作を行うコマンドを以下に記載します。

在kubectl命令的参数中，可以使用”replicaset”或”replicasets”来指定资源类型进行执行。同样地，也可以使用”rs”作为缩写进行指定。

kuard-rs.yaml

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: kuard
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: kuard
        version: "2"
    spec:
      containers:
        - name: kuard
          image: gcr.io/kuar-demo/kuard-amd64:2

kubectl apply -f kuard-rs.yaml

replicaset.extensions "kuard" created

kubectl get replicaset

NAME      DESIRED   CURRENT   READY     AGE
kuard     1         1         1         6s```

kubectl describe rs kuard

Name:         kuard
Namespace:    default
Selector:     app=kuard,version=2
Labels:       app=kuard
              version=2
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"extensions/v1beta1","kind":"ReplicaSet","metadata":{"annotations":{},"name":"kuard","namespace":"default"},"spec":{"replicas":1,"templat...
Replicas:     1 current / 1 desired
Pods Status:  1 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=kuard
           version=2
  Containers:
   kuard:
    Image:        gcr.io/kuar-demo/kuard-amd64:2
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  1m    replicaset-controller  Created pod: kuard-d65gb

kubectl scale replicasets kuard –replicas=4

replicaset.extensions "kuard" scaled

kubectl delete rs kuard

replicaset.extensions "kuard" deleted

服务 (fú wù)

Serviceは、サービスディスカバリを定義します。
サービスディスカバリとは、システム上のインフラにおけるサービスの問題を検出すると言うことを意味します。

例えば、マイクロサービスとしてサービスを提供しているコンテナにシステム障害が起きて停止した場合、障害が発生したコンテナ（Pod）に対するトラフィックを制御することができます。他にも、何らかのシステム障害発生時に、システム監視による検知でDNSレコードを更新したりして、DNSでサービスのディスカバリが行うことができます。

仕組みとして、各Podには固有のIPアドレスがありますが、それらのIPはServiceなしではクラスタの外部に公開されません。Serviceにより、アプリケーションはトラフィックを受信できます。

ClusterIP

デフォルトは、ClusterIPになります。ClusterIPはクラスタ内の内部にサービスを公開できます。ClusterIPにより、クラスタ内のPod間通信はServiceを介して行うことはできますが、外部からのアクセスはできません。

节点端口

使用网络地址转换（NAT）可以使外部访问集群成为可能。

负载均衡器

通常与云服务提供的负载均衡器配合使用。如果支持负载均衡器，则可以为服务分配固定的外部IP。

ExternalName

クラスタ内から外部のホストの名前解決を行うためのエイリアス（CNAME record）を設定することができます。なお、本機能はkube-dns v1.7以上になります。

进口

Kubernetes v1.1引入的Ingress功能允许从集群外部公开HTTP和HTTPS通信到集群内的Service。

工作

Job适用于批处理等任务，因为它会重复创建Pod直到指定数量的Pod成功处理完毕。

配置映射

在容器化运营中，重要的是在不损失容器特性的情况下进行运营。例如，为了修改具有Web服务器功能的容器的设置，更改Nginx的配置文件会降低其可移植性。通过使用环境变量，可以更容易地进行调整。关于环境变量的集成有很多方法，但Kubernetes提供了一个方便的功能叫ConfigMap。

ConfigMap的操作

以下是基本的ConfigMap操作命令，以kuard为例：

my-config.txt

parameter1 = value1
parameter2 = value2

kubectl create configmap my-config –from-file=my-config.txt –from-literal=extra-param=extra-value –from-literal=another-param=another-value

configmap "my-config" created

kubectl get configmap

NAME        DATA      AGE
my-config   3         2d

kubectl get configmap my-config -o yaml

apiVersion: v1
data:
  another-param: another-value
  extra-param: extra-value
  my-config.txt: |
    parameter1 = value1
    parameter2 = value2
kind: ConfigMap
metadata:
  creationTimestamp: 2019-04-25T06:23:43Z
  name: my-config
  namespace: default
  resourceVersion: "1030540"
  selfLink: /api/v1/namespaces/default/configmaps/my-config
  uid: ac8694d8-6722-11e9-97d1-025000000001

kubectl delete configmap my-config

configmap "my-config" deleted

部署

Deployment是一个能够在Kubernetes集群上对部署的应用程序进行版本管理的对象。通过Deployment，可以在不产生停机时间的情况下进行应用程序版本的切换。此外，Deployment还负责管理ReplicaSet。

部署操作

以下是执行基本的部署操作的命令。

在kubectl命令的参数中指定的资源类型可以是”deployment”或”deployments”，两者都可以执行。此外，也可以使用”deploy”进行缩写指定。

kubectl run nginx –image=nginx:1.7.12

kubectl run nginx --image=nginx:1.7.12

kubectl get deployment

kAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx     1         1         1            1           52s

kubectl describe deployment nginx

dName:                   nginx
Namespace:              default
CreationTimestamp:      Sat, 27 Apr 2019 16:13:52 +0900
Labels:                 run=nginx
Annotations:            deployment.kubernetes.io/revision=1
Selector:               run=nginx
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
Pod Template:
  Labels:  run=nginx
  Containers:
   nginx:
    Image:        nginx:1.7.12
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-7d9bf79f9b (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  29s   deployment-controller  Scaled up replica set nginx-7d9bf79f9b to 1

kubectl scale deployment nginx –replicas=2

deployment.extensions "nginx" scaled

kubectl delete deployment nginx

deployment.extensions "nginx" deleted

nginx-deployments.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: null
  generation: 1
  labels:
    run: nginx
  name: nginx
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      run: nginx
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx:1.7.12
        imagePullPolicy: IfNotPresent
        name: nginx
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status: {}

如果要以声明方式管理Deployment而不是使用kubectl scale命令，可以通过更改YAML文件中的副本数量，并使用kubectl apply命令来更新Deployment。同时，可以通过更改容器映像部分来实现新版本的滚动更新。

kubectl rollout status deployment nginx

deployment "nginx" successfully rolled out

kubectl get replicasets -o wide

NAME               DESIRED   CURRENT   READY     AGE       CONTAINERS   IMAGES                                             SELECTOR
nginx-784d96dbff   1         1         1         1m        nginx        nginx:1.9.10                                       pod-template-hash=3408528699,run=nginx
nginx-7d9bf79f9b   0         0         0         35m       nginx        nginx:1.7.12                                       pod-template-hash=3856935956,run=nginx

kubectl rollout history deployment nginx

deployments "nginx"
REVISION  CHANGE-CAUSE
1         <none>
2         Update nginx to 1.9.10

kubectl rollout history deployment nginx –revision=2

deployments "nginx" with revision #2
Pod Template:
  Labels:   pod-template-hash=3408528699
    run=nginx
  Annotations:  kubernetes.io/change-cause=Update nginx to 1.9.10
  Containers:
   nginx:
    Image:  nginx:1.9.10
    Port:   <none>
    Host Port:  <none>
    Environment:    <none>
    Mounts: <none>
  Volumes:  <none>

kubectl rollout undo deployment nginx

deployment.apps "nginx"

持久性卷 (chí jiǔ

Kubernetes有两种方法来为存储进行配置，静态和动态。

持久卷是为了管理独立的永久数据而静态提供的机制，与容器分开。此外，在Kubernetes中，它还支持NFS、iSCSI和云服务提供商特定的存储系统。

有关Persistent Volumes的使用方法，请参考“为Pod配置使用PersistentVolume进行存储”。

持久卷索取

创建永久卷后，还需要创建永久卷申请。
通过使用永久卷，可以进行逻辑存储分配，并允许Pod请求访问存储。

此外，通过使用StorageClasses对象，可以实现动态卷分配。

有关持久性卷的详细信息，请参考持久卷。

错误时的要点

以下是我在撰写本文时遇到的错误。

kubectl describe pod ポッド名の出力結果より、「Events」を見て、「Error: Couldn’t find key 環境変数 in ConfigMap 」のログが出力されていたら、ConfigMapの環境変数に謝りがあります。ConfigMapの環境変数が正しいか見直しましょう。

Warning  Failed                 4m (x7 over 5m)    kubelet, docker-for-desktop  Error: Couldn't find key extra-param in ConfigMap default/my-config

原因は、YAMLフォーマットの「spec」-「serviceName」で大文字を使用していたため。

Events:
  Type     Reason        Age               From                    Message
  ----     ------        ----              ----                    -------
  Warning  FailedCreate  3s (x10 over 5s)  statefulset-controller  create Pod mongo-0 in StatefulSet mongo failed error: Pod "mongo-0" is invalid: spec.subdomain: Invalid value: "Mongo": a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name',  or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')

最后

在成为DevOps工程师（※）的过程中，掌握Kubernetes是至关重要的技能。

此外，要进一步理解Kubernetes，还需要掌握容器化虚拟化技术和Linux等知识是必不可少的。

Kubernetesは深淵の海のように範囲が広く深いため、学習コストは高いですが、オンプレミスのインフラ経験を活かしてステップアップすることは十分に可能です。インフラエンジニアからDevOpsエンジニアへの階段を登りましょう。

在日本，所謂的基礎設施工程師包括本地伺服器（操作系統/中間件）和網路等廣泛的範疇。但是，他們也借鑒海外的開發和運營相結合的DevOps方法，並且構想了SRE（站點可靠性工程）的概念。

请引用以下内容为例，仅需要一个选项：

我们成立了一个小组来解决这个问题。

本記事で記載している一部のサンプルコードは、以下の書籍を参考にしています。

出典：日本語版「入門 Kubernetes」Kelsey Hightower、Brendan Burns、Joe Beda　著、オライリー・ジャパン、ISBN978-4-87311-840-6

公式：只需要一种选项，请用中文同义词表达。

kubectlのリファレンスドキュメント

GitHub (natively translated as 极速领科)

Virtual Kubelet

首先