Kubernetes

2018 年 4 月 20 日分類 devops, Docker, Kubernetes

# 项目简介

Kubernetes 是 Google 团队发起的开源项目，它的目标是管理跨多个主机的容器，提供基本的部署，维护以及应用伸缩，主要实现语言为 Go 语言。Kubernetes 是：

易学：轻量级，简单，容易理解
便携：支持公有云，私有云，混合云，以及多种云平台
可拓展：模块化，可插拔，支持钩子，可任意组合
自修复：自动重调度，自动重启，自动复制

Kubernetes 构建于 Google 数十年经验，一大半来源于 Google 生产环境规模的经验。结合了社区最佳的想法和实践。

在分布式系统中，部署，调度，伸缩一直是最为重要的也最为基础的功能。Kubernetes 就是希望解决这一序列问题的。

Kubernetes 目前在GitHub (opens new window)进行维护。

# Kubernetes 能够运行在任何地方！

虽然 Kubernetes 最初是为 GCE 定制的，但是在后续版本中陆续增加了其他云平台的支持，以及本地数据中心的支持。

# 基本概念

节点（Node）：一个节点是一个运行 Kubernetes 中的主机。
容器组（Pod）：一个 Pod 对应于由若干容器组成的一个容器组，同个组内的容器共享一个存储卷(volume)。
容器组生命周期（pos-states）：包含所有容器状态集合，包括容器组状态类型，容器组生命周期，事件，重启策略，以及 replication controllers。
Replication Controllers：主要负责指定数量的 pod 在同一时间一起运行。
服务（services）：一个 Kubernetes 服务是容器组逻辑的高级抽象，同时也对外提供访问容器组的策略。
卷（volumes）：一个卷就是一个目录，容器对其有访问权限。
标签（labels）：标签是用来连接一组对象的，比如容器组。标签可以被用来组织和选择子对象。
接口权限（accessing_the_api）：端口，IP 地址和代理的防火墙规则。
web 界面（ux）：用户可以通过 web 界面操作 Kubernetes。
命令行操作（cli）：kubectl命令。

# 节点

在 Kubernetes 中，节点是实际工作的点，节点可以是虚拟机或者物理机器，依赖于一个集群环境。每个节点都有一些必要的服务以运行容器组，并且它们都可以通过主节点来管理。必要服务包括 Docker，kubelet 和代理服务。

# 容器状态

容器状态用来描述节点的当前状态。现在，其中包含三个信息：

# 主机IP

主机 IP 需要云平台来查询，Kubernetes 把它作为状态的一部分来保存。如果 Kubernetes 没有运行在云平台上，节点 ID 就是必需的。IP 地址可以变化，并且可以包含多种类型的 IP 地址，如公共 IP，私有 IP，动态 IP，ipv6 等等。

# 节点周期

通常来说节点有 Pending，Running，Terminated 三个周期，如果 Kubernetes 发现了一个节点并且其可用，那么 Kubernetes 就把它标记为 Pending。然后在某个时刻，Kubernetes 将会标记其为 Running。节点的结束周期称为 Terminated。一个已经 Terminated 的节点不会接受和调度任何请求，并且已经在其上运行的容器组也会删除。

# 节点状态

节点的状态主要是用来描述处于 Running 的节点。当前可用的有 NodeReachable 和 NodeReady。以后可能会增加其他状态。NodeReachable 表示集群可达。NodeReady 表示 kubelet 返回 Status Ok 并且 HTTP 状态检查健康。

# 节点管理

节点并非 Kubernetes 创建，而是由云平台创建，或者就是物理机器、虚拟机。在 Kubernetes 中，节点仅仅是一条记录，节点创建之后，Kubernetes 会检查其是否可用。在 Kubernetes 中，节点用如下结构保存：

{
  "id": "10.1.2.3",
  "kind": "Minion",
  "apiVersion": "v1beta1",
  "resources": {
    "capacity": {
      "cpu": 1000,
      "memory": 1073741824
    },
  },
  "labels": {
    "name": "my-first-k8s-node",
  },
}

Kubernetes 校验节点可用依赖于 ID。在当前的版本中，有两个接口可以用来管理节点：节点控制和 Kube 管理。

# 节点控制

在 Kubernetes 主节点中，节点控制器是用来管理节点的组件。主要包含：

集群范围内节点同步
单节点生命周期管理

节点控制有一个同步轮寻，主要监听所有云平台的虚拟实例，会根据节点状态创建和删除。可以通过 --node_sync_period标志来控制该轮寻。如果一个实例已经创建，节点控制将会为其创建一个结构。同样的，如果一个节点被删除，节点控制也会删除该结构。在 Kubernetes 启动时可用通过 --machines标记来显示指定节点。同样可以使用 kubectl 来一条一条的添加节点，两者是相同的。通过设置 --sync_nodes=false标记来禁止集群之间的节点同步，你也可以使用 api/kubectl 命令行来增删节点。

# 容器组

在 Kubernetes 中，使用的最小单位是容器组，容器组是创建，调度，管理的最小单位。一个容器组使用相同的 Docker 容器并共享卷（挂载点）。一个容器组是一个特定应用的打包集合，包含一个或多个容器。

和运行的容器类似，一个容器组被认为只有很短的运行周期。容器组被调度到一组节点运行，直到容器的生命周期结束或者其被删除。如果节点死掉，运行在其上的容器组将会被删除而不是重新调度。（也许在将来的版本中会添加容器组的移动）。

# 容器组设计的初衷

# 资源共享和通信

容器组主要是为了数据共享和它们之间的通信。

在一个容器组中，容器都使用相同的网络地址和端口，可以通过本地网络来相互通信。每个容器组都有独立的 IP，可用通过网络来和其他物理主机或者容器通信。

容器组有一组存储卷（挂载点），主要是为了让容器在重启之后可以不丢失数据。

# 容器组管理

容器组是一个应用管理和部署的高层次抽象，同时也是一组容器的接口。容器组是部署、水平放缩的最小单位。

# 容器组的使用

容器组可以通过组合来构建复杂的应用，其本来的意义包含：

内容管理，文件和数据加载以及本地缓存管理等。
日志和检查点备份，压缩，快照等。
监听数据变化，跟踪日志，日志和监控代理，消息发布等。
代理，网桥
控制器，管理，配置以及更新

# 替代方案

为什么不在一个单一的容器里运行多个程序？

1.透明化。为了使容器组中的容器保持一致的基础设施和服务，比如进程管理和资源监控。这样设计是为了用户的便利性。
2.解偶软件之间的依赖。每个容器都可能重新构建和发布，Kubernetes 必须支持热发布和热更新（将来）。
3.方便使用。用户不必运行独立的程序管理，也不用担心每个应用程序的退出状态。
4.高效。考虑到基础设施有更多的职责，容器必须要轻量化。

# 容器组的生命状态

包括若干状态值：pending、running、succeeded、failed。

# pending

容器组已经被节点接受，但有一个或多个容器还没有运行起来。这将包含某些节点正在下载镜像的时间，这种情形会依赖于网络情况。

# running

容器组已经被调度到节点，并且所有的容器都已经启动。至少有一个容器处于运行状态（或者处于重启状态）。

# succeeded

所有的容器都正常退出。

# failed

容器组中所有容器都意外中断了。

# 容器组生命周期

通常来说，如果容器组被创建了就不会自动销毁，除非被某种行为触发，而触发此种情况可能是人为，或者复制控制器所为。唯一例外的是容器组由 succeeded 状态成功退出，或者在一定时间内重试多次依然失败。

如果某个节点死掉或者不能连接，那么节点控制器将会标记其上的容器组的状态为 failed。

举例如下。

容器组状态 running，有 1 容器，容器正常退出
- 记录完成事件
- 如果重启策略为：
  - 始终：重启容器，容器组保持 running
  - 失败时：容器组变为 succeeded
  - 从不：容器组变为 succeeded
容器组状态 running，有1容器，容器异常退出
- 记录失败事件
- 如果重启策略为：
  - 始终：重启容器，容器组保持 running
  - 失败时：重启容器，容器组保持 running
  - 从不：容器组变为 failed
容器组状态 running，有2容器，有1容器异常退出
- 记录失败事件
- 如果重启策略为：
  - 始终：重启容器，容器组保持 running
  - 失败时：重启容器，容器组保持 running
  - 从不：容器组保持 running
- 当有2容器退出
  - 记录失败事件
  - 如果重启策略为：
    - 始终：重启容器，容器组保持 running
    - 失败时：重启容器，容器组保持 running
    - 从不：容器组变为 failed
容器组状态 running，容器内存不足
- 标记容器错误中断
- 记录内存不足事件
- 如果重启策略为：
  - 始终：重启容器，容器组保持 running
  - 失败时：重启容器，容器组保持 running
  - 从不：记录错误事件，容器组变为 failed
容器组状态 running，一块磁盘死掉
- 杀死所有容器
- 记录事件
- 容器组变为 failed
- 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建
容器组状态 running，对应的节点段溢出
- 节点控制器等到超时
- 节点控制器标记容器组 failed
- 如果容器组运行在一个控制器下，容器组将会在其他地方重新创建

# Replication Controllers

# 服务

# 卷

# 标签

# 接口权限

# web界面

# 命令行操作

# 基本架构

任何优秀的项目都离不开优秀的架构设计。本小节将介绍 Kubernetes 在架构方面的设计考虑。

# 基本考虑

如果让我们自己从头设计一套容器管理平台，有如下几个方面是很容易想到的：

分布式架构，保证扩展性；
逻辑集中式的控制平面 + 物理分布式的运行平面；
一套资源调度系统，管理哪个容器该分配到哪个节点上；
一套对容器内服务进行抽象和 HA 的系统。

# 运行原理

下面这张图完整展示了 Kubernetes 的运行原理。

Kubernetes 架构

可见，Kubernetes 首先是一套分布式系统，由多个节点组成，节点分为两类：一类是属于管理平面的主节点/控制节点（Master Node）；一类是属于运行平面的工作节点（Worker Node）。

显然，复杂的工作肯定都交给控制节点去做了，工作节点负责提供稳定的操作接口和能力抽象即可。

从这张图上，我们没有能发现 Kubernetes 中对于控制平面的分布式实现，但是由于数据后端自身就是一套分布式的数据库 Etcd，因此可以很容易扩展到分布式实现。

# 控制平面

# 主节点服务

主节点上需要提供如下的管理服务：

apiserver 是整个系统的对外接口，提供一套 RESTful 的 Kubernetes API (opens new window)，供客户端和其它组件调用；
scheduler 负责对资源进行调度，分配某个 pod 到某个节点上。是 pluggable 的，意味着很容易选择其它实现方式；
controller-manager 负责管理控制器，包括 endpoint-controller（刷新服务和 pod 的关联信息）和 replication-controller（维护某个 pod 的复制为配置的数值）。

# Etcd

这里 Etcd 即作为数据后端，又作为消息中间件。

通过 Etcd 来存储所有的主节点上的状态信息，很容易实现主节点的分布式扩展。

组件可以自动的去侦测 Etcd 中的数值变化来获得通知，并且获得更新后的数据来执行相应的操作。

# 工作节点

kubelet 是工作节点执行操作的 agent，负责具体的容器生命周期管理，根据从数据库中获取的信息来管理容器，并上报 pod 运行状态等；
kube-proxy 是一个简单的网络访问代理，同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上的 Pod（同一类标签）。

Proxy 代理对服务的请求

Docker 从入门到实践

微信交流群 (opens new window)

小程序 (opens new window)

云服务器99/元首年特惠 (opens new window)

GitHub (opens new window)

部署 Kubernetes

小于 1 分钟约 102 字

# 部署 Kubernetes

目前，Kubernetes 支持在多种环境下使用，包括本地主机（Ubuntu、Debian、CentOS、Fedora 等）、云服务（腾讯云 (opens new window)、阿里云 (opens new window)、百度云 (opens new window) 等）。

你可以使用以下几种方式部署 Kubernetes：

kubeadm
docker-desktop
k3s

接下来的小节会对以上几种方式进行详细介绍。

基本架构使用 kubeadm 部署 kubernetes(CRI 使用 containerd)

# 使用 kubeadm 部署 kubernetes(CRI 使用 containerd)

kubeadm 提供了 kubeadm init 以及 kubeadm join 这两个命令作为快速创建 kubernetes 集群的最佳实践。

# 安装 containerd

参考安装 Docker 一节添加 apt/yum 源，之后执行如下命令。

# debian 系
$ sudo apt install containerd.io

# rhel 系
$ sudo yum install containerd.io

# 配置 containerd

新建 /etc/systemd/system/cri-containerd.service 文件

[Unit]
Description=containerd container runtime for kubernetes
Documentation=https://containerd.io
After=network.target local-fs.target

[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/bin/containerd --config //etc/cri-containerd/config.toml

Type=notify
Delegate=yes
KillMode=process
Restart=always
RestartSec=5
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
LimitNOFILE=infinity
# Comment TasksMax if your systemd version does not supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity
OOMScoreAdjust=-999

[Install]
WantedBy=multi-user.target

新建 /etc/cri-containerd/config.toml containerd 配置文件

version = 2
# persistent data location
root = "/var/lib/cri-containerd"
# runtime state information
state = "/run/cri-containerd"
plugin_dir = ""
disabled_plugins = []
required_plugins = []
# set containerd's OOM score
oom_score = 0

[grpc]
  address = "/run/cri-containerd/cri-containerd.sock"
  tcp_address = ""
  tcp_tls_cert = ""
  tcp_tls_key = ""
  # socket uid
  uid = 0
  # socket gid
  gid = 0
  max_recv_message_size = 16777216
  max_send_message_size = 16777216

[debug]
  address = ""
  format = "json"
  uid = 0
  gid = 0
  level = ""

[metrics]
  address = "127.0.0.1:1338"
  grpc_histogram = false

[cgroup]
  path = ""

[timeouts]
  "io.containerd.timeout.shim.cleanup" = "5s"
  "io.containerd.timeout.shim.load" = "5s"
  "io.containerd.timeout.shim.shutdown" = "3s"
  "io.containerd.timeout.task.state" = "2s"

[plugins]
  [plugins."io.containerd.gc.v1.scheduler"]
    pause_threshold = 0.02
    deletion_threshold = 0
    mutation_threshold = 100
    schedule_delay = "0s"
    startup_delay = "100ms"
  [plugins."io.containerd.grpc.v1.cri"]
    disable_tcp_service = true
    stream_server_address = "127.0.0.1"
    stream_server_port = "0"
    stream_idle_timeout = "4h0m0s"
    enable_selinux = false
    selinux_category_range = 1024
    sandbox_image = "registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.5"
    stats_collect_period = 10
    # systemd_cgroup = false
    enable_tls_streaming = false
    max_container_log_line_size = 16384
    disable_cgroup = false
    disable_apparmor = false
    restrict_oom_score_adj = false
    max_concurrent_downloads = 3
    disable_proc_mount = false
    unset_seccomp_profile = ""
    tolerate_missing_hugetlb_controller = true
    disable_hugetlb_controller = true
    ignore_image_defined_volumes = false
    [plugins."io.containerd.grpc.v1.cri".containerd]
      snapshotter = "overlayfs"
      default_runtime_name = "runc"
      no_pivot = false
      disable_snapshot_annotations = false
      discard_unpacked_layers = false
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
        [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
          runtime_type = "io.containerd.runc.v2"
          pod_annotations = []
          container_annotations = []
          privileged_without_host_devices = false
          base_runtime_spec = ""
          [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
            # SystemdCgroup enables systemd cgroups.
            SystemdCgroup = true
            # BinaryName is the binary name of the runc binary.
            # BinaryName = "runc"
            # BinaryName = "crun"
            # NoPivotRoot disables pivot root when creating a container.
            # NoPivotRoot = false

            # NoNewKeyring disables new keyring for the container.
            # NoNewKeyring = false

            # ShimCgroup places the shim in a cgroup.
            # ShimCgroup = ""

            # IoUid sets the I/O's pipes uid.
            # IoUid = 0

            # IoGid sets the I/O's pipes gid.
            # IoGid = 0

            # Root is the runc root directory.
            Root = ""

            # CriuPath is the criu binary path.
            # CriuPath = ""

            # CriuImagePath is the criu image path
            # CriuImagePath = ""

            # CriuWorkPath is the criu work path.
            # CriuWorkPath = ""
    [plugins."io.containerd.grpc.v1.cri".cni]
      bin_dir = "/opt/cni/bin"
      conf_dir = "/etc/cni/net.d"
      max_conf_num = 1
      conf_template = ""
    [plugins."io.containerd.grpc.v1.cri".registry]
      config_path = "/etc/cri-containerd/certs.d"
      [plugins."io.containerd.grpc.v1.cri".registry.headers]
        # Foo = ["bar"]
    [plugins."io.containerd.grpc.v1.cri".image_decryption]
      key_model = ""
    [plugins."io.containerd.grpc.v1.cri".x509_key_pair_streaming]
      tls_cert_file = ""
      tls_key_file = ""
  [plugins."io.containerd.internal.v1.opt"]
    path = "/opt/cri-containerd"
  [plugins."io.containerd.internal.v1.restart"]
    interval = "10s"
  [plugins."io.containerd.metadata.v1.bolt"]
    content_sharing_policy = "shared"
  [plugins."io.containerd.monitor.v1.cgroups"]
    no_prometheus = false
  [plugins."io.containerd.runtime.v2.task"]
    platforms = ["linux/amd64"]
  [plugins."io.containerd.service.v1.diff-service"]
    default = ["walking"]
  [plugins."io.containerd.snapshotter.v1.devmapper"]
    root_path = ""
    pool_name = ""
    base_image_size = ""
    async_remove = false

# 安装 kubelet kubeadm kubectl cri-tools kubernetes-cni

# Ubuntu/Debian

$ apt-get update && apt-get install -y apt-transport-https
$ curl https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | apt-key add -

$ cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main
EOF

$ apt-get update
$ apt-get install -y kubelet kubeadm kubectl

# CentOS/Fedora

$ cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

$ sudo yum install -y kubelet kubeadm kubectl

# 修改内核的运行参数

$ cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

# 应用配置
$ sysctl --system

# 配置 kubelet

# 修改 `kubelet.service`

/etc/systemd/system/kubelet.service.d/10-proxy-ipvs.conf 写入以下内容

# 启用 ipvs 相关内核模块
[Service]
ExecStartPre=-/sbin/modprobe ip_vs
ExecStartPre=-/sbin/modprobe ip_vs_rr
ExecStartPre=-/sbin/modprobe ip_vs_wrr
ExecStartPre=-/sbin/modprobe ip_vs_sh

执行以下命令应用配置。

1	$ sudo systemctl daemon-reload

# 部署

# master

$ systemctl enable cri-containerd

$ systemctl start cri-containerd

$ sudo kubeadm init \
      --image-repository registry.cn-hangzhou.aliyuncs.com/google_containers \
      --pod-network-cidr 10.244.0.0/16 \
      --cri-socket /run/cri-containerd/cri-containerd.sock \
      --v 5 \
      --ignore-preflight-errors=all

--pod-network-cidr 10.244.0.0/16 参数与后续 CNI 插件有关，这里以 flannel 为例，若后续部署其他类型的网络插件请更改此参数。

执行可能出现错误，例如缺少依赖包，根据提示安装即可。

执行成功会输出

...
[addons] Applied essential addon: CoreDNS
I1116 12:35:13.270407   86677 request.go:538] Throttling request took 181.409184ms, request: POST:https://192.168.199.100:6443/api/v1/namespaces/kube-system/serviceaccounts
I1116 12:35:13.470292   86677 request.go:538] Throttling request took 186.088112ms, request: POST:https://192.168.199.100:6443/api/v1/namespaces/kube-system/configmaps
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.199.100:6443 --token cz81zt.orsy9gm9v649e5lf \
    --discovery-token-ca-cert-hash sha256:5edb316fd0d8ea2792cba15cdf1c899a366f147aa03cba52d4e5c5884ad836fe

# node 工作节点

在 另一主机 重复部署小节以前的步骤，安装配置好 kubelet。根据提示，加入到集群。

$ systemctl enable cri-containerd

$ systemctl start cri-containerd

$ kubeadm join 192.168.199.100:6443 \
    --token cz81zt.orsy9gm9v649e5lf \
    --discovery-token-ca-cert-hash sha256:5edb316fd0d8ea2792cba15cdf1c899a366f147aa03cba52d4e5c5884ad836fe \
    --cri-socket /run/cri-containerd/cri-containerd.sock

# 查看服务

所有服务启动后，通过 crictl 查看本地实际运行的容器。这些服务大概分为三类：主节点服务、工作节点服务和其它服务。

1	CONTAINER_RUNTIME_ENDPOINT=/run/cri-containerd/cri-containerd.sock crictl ps -a

# 主节点服务

apiserver 是整个系统的对外接口，提供 RESTful 方式供客户端和其它组件调用；
scheduler 负责对资源进行调度，分配某个 pod 到某个节点上；
controller-manager 负责管理控制器，包括 endpoint-controller（刷新服务和 pod 的关联信息）和 replication-controller（维护某个 pod 的复制为配置的数值）。

# 工作节点服务

proxy 为 pod 上的服务提供访问的代理。

# 其它服务

Etcd 是所有状态的存储数据库；

# 使用

将 /etc/kubernetes/admin.conf 复制到 ~/.kube/config

执行 $ kubectl get all -A 查看启动的服务。

由于未部署 CNI 插件，CoreDNS 未正常启动。如何使用 Kubernetes，请参考后续章节。

# 部署 CNI

这里以 flannel 为例进行介绍。

# flannel

检查 podCIDR 设置

$ kubectl get node -o yaml | grep CIDR

# 输出
    podCIDR: 10.244.0.0/16
    podCIDRs:

1	$ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.11.0/Documentation/kube-flannel.yml

# master 节点默认不能运行 pod

如果用 kubeadm 部署一个单节点集群，默认情况下无法使用，请执行以下命令解除限制

$ kubectl taint nodes --all node-role.kubernetes.io/master-

# 恢复默认值
# $ kubectl taint nodes NODE_NAME node-role.kubernetes.io/master=true:NoSchedule

# 参考文档

# Docker Desktop 启用 Kubernetes

使用 Docker Desktop 可以很方便的启用 Kubernetes，由于国内获取不到 k8s.gcr.io 镜像，我们必须首先解决这一问题。

# 获取 `k8s.gcr.io` 镜像

由于国内拉取不到 k8s.gcr.io 镜像，我们可以使用开源项目 AliyunContainerService/k8s-for-docker-desktop (opens new window) 来获取所需的镜像。

# 启用 Kubernetes

在 Docker Desktop 设置页面，点击 Kubernetes，选择 Enable Kubernetes，稍等片刻，看到左下方 Kubernetes 变为 running，Kubernetes 启动成功。

# 测试

1	$ kubectl version

如果正常输出信息，则证明 Kubernetes 成功启动。

# Kubernetes Dashboard

Kubernetes Dashboard (opens new window) 是基于网页的 Kubernetes 用户界面。

# 部署

执行以下命令即可部署 Dashboard：

1	kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml

# 访问

通过命令行代理访问，执行以下命令：

到 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 即可访问。

# 登录

目前，Dashboard 仅支持使用 Bearer 令牌登录。下面教大家如何创建该令牌：

$ kubectl create sa dashboard-admin -n kube-system

$ kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin

$ ADMIN_SECRET=$(kubectl get secrets -n kube-system | grep dashboard-admin | awk '{print $1}')

$ DASHBOARD_LOGIN_TOKEN=$(kubectl describe secret -n kube-system ${ADMIN_SECRET} | grep -E '^token' | awk '{print $2}')

echo ${DASHBOARD_LOGIN_TOKEN}

将结果粘贴到登录页面，即可登录。

# 参考文档

官方文档 (opens new window)

留言與分享

Kubernetes

# 项目简介

# Kubernetes 能够运行在任何地方！

# 基本概念

# 节点

# 容器状态

# 主机IP

# 节点周期

# 节点状态

# 节点管理

# 节点控制

# 容器组

# 容器组设计的初衷

# 资源共享和通信

# 容器组管理

# 容器组的使用

# 替代方案

# 容器组的生命状态

# pending

# running

# succeeded

# failed

# 容器组生命周期

# Replication Controllers

# 服务

# 卷

# 标签

# 接口权限

# web界面

# 命令行操作

# 基本架构

# 基本考虑

# 运行原理

# 控制平面

# 主节点服务

# Etcd

# 工作节点

部署 Kubernetes

# 部署 Kubernetes

# 使用 kubeadm 部署 kubernetes(CRI 使用 containerd)

# 安装 containerd

# 配置 containerd

# 安装 kubelet kubeadm kubectl cri-tools kubernetes-cni

# Ubuntu/Debian

# CentOS/Fedora

# 修改内核的运行参数

# 配置 kubelet

# 修改 kubelet.service

# 部署

# master

# node 工作节点

# 查看服务

# 主节点服务

# 工作节点服务

# 其它服务

# 使用

# 部署 CNI

# flannel

# master 节点默认不能运行 pod

# 参考文档

# Docker Desktop 启用 Kubernetes

# 获取 k8s.gcr.io 镜像

# 启用 Kubernetes

# 测试

# Kubernetes Dashboard

# 部署

# 访问

# 登录

# 参考文档

Kein Chan

R语言-环境安装

R语言-基础

R语言-读取数据

R语言-绘图

R语言-线性回归

1. 算法在计算中的作用

2. 算法基础

3. 函数的增长

4. 分治策略

5. 概率分析和随机算法

# 修改 `kubelet.service`

# 获取 `k8s.gcr.io` 镜像