Adsense
This commit is contained in:
huanqing.shao
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# Kubernetes免费中文教程
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
|
||||
本教程的主要依据是：Kubernetes 官网文档，以及使用 Kubernetes 落地 Spring Cloud 微服务并投产的实战经验。适用人群：
|
||||
* Kubernetes 初学者
|
||||
|
||||
@ -6,6 +6,8 @@ description: Kubernetes教程_高级篇_主要涉及日志采集_安全_监控_
|
||||
|
||||
# Kubernetes教程深入篇
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
Kubernetes教程的深入篇部分，主要涉及的内容有如下几个方面：
|
||||
|
||||
* [问题诊断](./ts/application.html)
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 基本的日志
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本章节中，您将了解到如何在 Kubernetes 中使用最基本的日志，此时，日志信息将输出到标准输出流（standard output stream）。请参考下面的例子，该例子中的 Pod 包含一个容器，该容器每秒钟向标准输出写入一些文本内容：
|
||||
|
||||
<<< @/.vuepress/public/statics/learning/logs/counter-pod.yaml
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 集群级别的日志
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
Kubernetes 中并不默认提供集群级别的日志，不过，有许多种途径可以和集群级别的日志整合。例如：
|
||||
* 在每个节点上配置日志代理
|
||||
* 在应用程序的 Pod 中包含一个专门用于收集日志的 sidecar 容器
|
||||
|
||||
@ -9,4 +9,6 @@ meta:
|
||||
|
||||
# 使用ELK作为集群级别的日志
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
待更新 ...
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 日志架构
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Logging Architecture](https://kubernetes.io/docs/concepts/cluster-administration/logging/)
|
||||
|
||||
当集群中出现任何问题时，应用程序日志和系统日志是非常有效的定位问题的手段，可以让我们知道集群中正在发生的事情。绝大多数的应用程序都有日志机制，主流的容器引擎也都支持某种形式的日志。对容器化应用程序来说，最简单也是被采纳得最多的一种日志方式是，将日志写入到标准输出流（例如，Java中的 `System.out.println` 语句，或 log4j 中的 Console Appender）和标准错误流里（例如，Java中的 `System.error.println` 语句）
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 节点级别的日志
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 日志存储
|
||||
|
||||
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 调度
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Kubernetes Scheduler](https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/)
|
||||
|
||||
在Kubernetes中，调度（Scheduling），指的是为 Pod 找到一个合适的节点，并由该节点上的 kubelet 运行 Pod。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 诊断应用程序
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Troubleshoot Applications](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application/)
|
||||
|
||||
本文档可帮助您诊断部署到Kubernetes中的应用程序所出现的问题。如果仍然解决不了，请加本文末尾的QQ群答疑。也可以了解 [更多支持方式](/support/)
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 诊断集群问题
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档：[Troubleshoot Clusters](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-cluster/)
|
||||
|
||||
本文主要是关于如何诊断集群出现的问题，此时，假设您已经经过排查，确认当前碰到问题的 root cause（问题的根源）不是应用程序的问题。参考 [诊断应用程序](./application.html)。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 1.部署一个应用程序
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文翻译自 Kubernetes 官网 [Using kubectl to Create a Deployment](https://kubernetes.io/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/) ，并有所改写
|
||||
|
||||
### 前提
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 2.查看Pods/Nodes
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文翻译自 Kubernetes 官网 [Viewing Pods and Nodes](https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/) ，并有所改写
|
||||
|
||||
## 目标
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 3.公布应用程序
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文翻译自 Kubernetes 官网 [Using a Service to Expose Your App](https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/) ，并有所改写
|
||||
|
||||
## 目标
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 6.复习Kubernetes核心概念
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 转载信息：
|
||||
>
|
||||
> 译者：崔婧雯
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 0.学习Kubernetes基础知识
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文翻译自 Kubernetes 官网 [Learn Kubernetes Basics](https://kubernetes.io/docs/tutorials/kubernetes-basics/) ，并有所改写
|
||||
|
||||
相信很多初学者在入门 Kubernetes (以下简称k8s)时，都会被各种英文单词所困扰(例如：Deployment、Pod、Service等)，这些名词在被翻译后也往往失去了原意，更不能体现出他们的相互关系。笔者在刚开始学习k8s时也遭遇到这种困境。但是，任何复杂的系统都是发源于最基本的公式或定理，k8s虽然庞大且复杂，不过只要抓住一些基本的脉络(一些最基本的组件的定义及使用)，入门便也是毫不费劲。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 4.伸缩应用程序
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文翻译自 Kubernetes 官网 [Running Multiple Instances of Your App](https://kubernetes.io/docs/tutorials/kubernetes-basics/scale/scale-intro/) ，并有所改写
|
||||
|
||||
## 目标
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 5.执行滚动更新
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文翻译自 Kubernetes 官网 [Performing a Rolling Update](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/) ，并有所改写
|
||||
|
||||
## 目标
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# Master to Cluster
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
从 master（apiserver）到Cluster存在着两条主要的通信路径：
|
||||
* apiserver 访问集群中每个节点上的 kubelet 进程
|
||||
* 使用 apiserver 的 proxy 功能，从 apiserver 访问集群中的任意节点、Pod、Service
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Cluster to Master
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
所有从集群访问 Master 节点的通信，都是针对 apiserver 的（没有任何其他 master 组件发布远程调用接口）。通常安装 Kubernetes 时，apiserver 监听 HTTPS 端口（443），并且配置了一种或多种 [客户端认证方式 authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)。至少需要配置一种形式的 [授权方式 authorization](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)，尤其是 [匿名访问 anonymous requests](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests) 或 [Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) 被启用的情况下。
|
||||
|
||||
节点上必须配置集群（apiserver）的公钥根证书（public root certificate），此时，在提供有效的客户端身份认证的情况下，节点可以安全地访问 APIServer。例如，在 Google Kubernetes Engine 的一个默认 Kubernetes 安装里，通过客户端证书为 kubelet 提供客户端身份认证。请参考 [kubelet TLS bootstrapping](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)，了解如何自动为 kubelet 提供客户端证书。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Master-Node之间的通信
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文描述了Kubernetes集群和Master节点（实际上是 apiserver）之间的通信路径。用户在自定义集群的安装之前，或者调整集群的网络配置之前必须理解这部分内容。例如：
|
||||
* 从 [安装Kubernetes单Master节点](/install/install-k8s.html) 的安装结果调整到 [安装Kubernetes高可用](/install/install-kubernetes.html) 的安装结果
|
||||
* 将公网 IP 地址上的机器作为节点加入到 Kubernetes 集群
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 控制器
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
在机器人技术和自动化技术中，**控制循环** 是一个控制系统状态的无限循环。房间里的恒温器就是**控制循环**的一个例子
|
||||
|
||||
* 在恒温器上设定好目标温度，就是在告诉该 **控制循环** 你想要的 ***目标状态***。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 节点管理
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
与 Pod 和 Service 不一样，节点并不是由 Kubernetes 创建的，节点由云供应商（例如，Google Compute Engine、阿里云等）创建，或者节点已经存在于您的物理机/虚拟机的资源池。向 Kubernetes 中创建节点时，仅仅是创建了一个描述该节点的 API 对象。节点 API 对象创建成功后，Kubernetes将检查该节点是否有效。例如，假设您创建如下节点信息：
|
||||
|
||||
``` yaml
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 节点
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
Kubernetes中节点（node）指的是一个工作机器，曾经叫做 `minion`。不同的集群中，节点可能是虚拟机也可能是物理机。每个节点都由 master 组件管理，并包含了运行 Pod（容器组）所需的服务。这些服务包括：
|
||||
* [容器引擎](/learning/k8s-bg/component.html#容器引擎)
|
||||
* kubelet
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Kubernetes组件
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Kubernetes Components](https://kubernetes.io/docs/concepts/overview/components/)
|
||||
|
||||
本文档描述了 Kubernetes 的主要组件。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Kubernetes介绍
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [What is Kubernetes](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
|
||||
|
||||
Kubernetes是一个可以移植、可扩展的开源平台，使用 [声明式的配置](/learning/k8s-intermediate/workload/wl-deployment/#deployment-概述) 并依据配置信息自动地执行容器化应用程序的管理。在所有的容器编排工具中（类似的还有 docker swarm / mesos等），Kubernetes的生态系统更大、增长更快，有更多的支持、服务和工具可供用户选择。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 将容器组调度到指定的节点
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网 [Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/)
|
||||
|
||||
## 概述
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 管理容器的计算资源
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网 [Managing Compute Resources for Containers](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)
|
||||
|
||||
## 概述
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 使用ConfigMap配置您的应用程序
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文参考了 Kubernetes 官网 [Configure a Pod to Use a ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap)，并有所改写
|
||||
|
||||
Kubernetes ConfigMap 可以将配置信息和容器镜像解耦，以使得容器化的应用程序可移植。本文提供了一系列的实例，解释如何通过 Kuboard 创建 ConfigMap 以及如何使用 ConfigMap 中的数据配置 Pod（容器组）。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 为容器设置Linux Capabilities
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
使用 [Linux Capabilities](http://man7.org/linux/man-pages/man7/capabilities.7.html) 可以为容器内的进程授予某些特定的权限（而不是 root 用户的所有权限）。在容器定义的 `securityContext` 中添加 `capabilities` 字段，可以向容器添加或删除 Linux Capability。
|
||||
|
||||
本文后续章节中，先运行一个不包含 `capabilities` 字段的容器，观察容器内进程的 linux capabilities 位图的情况；然后在运行一个包含 `capabilities` 字段的容器，比较其 linux capabilities 位图与前者的不同。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Kuboard中容器的Security Context
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
通过 Kuboard，可以直接设定 Deployment、StatefulSet、DaemonSet 等中容器的 securityContext 的内容。在 Kuboard 工作负载编辑器界面中点击 **容器组的更多设定** 按钮，可查看到容器的 Security Context 设置界面，如下图所示：
|
||||
|
||||
|
||||
@ -28,4 +30,3 @@ meta:
|
||||
| procMount | string | procMount 代表了容器的 proc mount 的类型。默认值是 `DefaultProcMount`（使用容器引擎的默认值）。该字段需要激活 Kubernetes 的ProcMountType 特性 |
|
||||
| capabilities | <div style="width: 80px;">add: array<br />drop: array</div> | 为容器进程 add/drop Linux capabilities。默认使用容器引擎的设定。更多内容请参考 [为容器设置Linux Capabilities](./con-cap.html) |
|
||||
| seLinuxOptions | | 此字段设定的 SELinux 上下文将被应用到 Pod 中所有容器。如果不指定，容器引擎将为每个容器分配一个随机的 SELinux 上下文。<font color="grey">也可以在Pod的SecurityContext中设定，如果 Pod 和容器的 securityContext 中都设定了这个字段，则对该容器来说以容器中的设置为准。</font> |
|
||||
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 为容器设置SELinux标签
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
Pod 或容器定义的 `securityContext` 中 `seLinuxOptions` 字段是一个 [SELinuxOptions](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#selinuxoptions-v1-core) 对象，该字段可用于为容器指定 SELinux 标签。如下所示：
|
||||
|
||||
``` yaml
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 为容器设置Security Context
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
容器的定义中包含 `securityContext` 字段，该字段接受 [SecurityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#securitycontext-v1-core) 对象。通过指定该字段，可以为容器设定安全相关的配置，当该字段的配置与 Pod 级别的 `securityContext` 配置相冲突时，容器级别的配置将覆盖 Pod 级别的配置。容器级别的 `securityContext` 不影响 Pod 中的数据卷。
|
||||
|
||||
下面的示例中的 Pod 包含一个 Container，且 Pod 和 Container 都有定义 `securityContext` 字段：
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 概述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档：Kubernetes 官网文档 [Configure a Security Context for a Pod or Container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container)
|
||||
|
||||
Security Context（安全上下文）用来限制容器对宿主节点的可访问范围，以避免容器非法操作宿主节点的系统级别的内容，使得节点的系统或者节点上其他容器组受到影响。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Kuboard中Pod的Security Context
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
通过 Kuboard，可以直接设定 Deployment、StatefulSet、DaemonSet 等中 Pod 模板的 securityContext 的内容。在 Kuboard 工作负载编辑器界面中点击 **容器组的更多设定** 按钮，可查看到 Pod 的 Security Context 设置界面，如下图所示：
|
||||
|
||||
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 为Pod设置Security Context
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
在 Pod 的定义中增加 `securityContext` 字段，即可为 Pod 指定 Security 相关的设定。 `securityContext` 字段是一个 [PodSecurityContext](./pod-kuboard.html) 对象。通过该字段指定的内容将对该 Pod 中所有的容器生效。
|
||||
|
||||
## Pod示例
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 关于数据卷
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
Pod 的 securityContext 作用于 Pod 中所有的容器，同时对 Pod 的数据卷也同样生效。具体来说，`fsGroup` 和 `seLinuxOptions` 将被按照如下方式应用到 Pod 中的数据卷：
|
||||
* `fsGroup`：对于支持 ownership 管理的数据卷，通过 `fsGroup` 指定的 GID 将被设置为该数据卷的 owner，并且可被 `fsGroup` 写入。更多细节请参考 [Ownership Management design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/volume-ownership-management.md)
|
||||
* `seLinuxOptions`：对于支持 SELinux 标签的数据卷，将按照 `seLinuxOptions` 的设定重新打标签，以使 Pod 可以访问数据卷内容。通常您只需要设置 `seLinuxOptions` 中 `level` 这一部分内容。该设定为 Pod 中所有容器及数据卷设置 [Multi-Category Security (MCS)](https://selinuxproject.org/page/NB_MLS) 标签。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建Secret（使用Generator）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
从 kubernetes v1.14 开始，kubectl 集成了 [Kustomize](https://kustomize.io/)。通过 Kustomize，您可以使用 generator（Kustomize 的概念）创建 Secret，并保存到 API Server。Generator 必须在 `kustomization.yaml` 文件中指定。
|
||||
|
||||
::: tip
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建Secret（使用kubectl）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
假设某个 Pod 需要访问数据库。在您执行 kubectl 命令所在机器的当前目录，创建文件 `./username.txt` 文件和 `./password.txt` 暂存数据库的用户名和密码，后续我们根据这两个文件配置 kubernetes secrets。
|
||||
|
||||
```sh
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建Secret（使用Kuboard）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文简要描述如何在 Kuboard 中创建 Kubernetes Secret。
|
||||
|
||||
Kubernetes Secret 必须从属于某一个名称空间，进入 Kuboard 名称空间界面，Secret 列表在名称空间的左上角。如下图所示：
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建Secret（手动）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
和创建其他类型的 API 对象（Pod、Deployment、StatefulSet、ConfigMap 等）一样，您也可以先在 yaml 文件中定义好 Secret，然后通过 `kubectl apply -f` 命令创建。此时，您可以通过如下两种方式在 yaml 文件中定义 Secret：
|
||||
* **data**：使用 data 字段时，取值的内容必须是 base64 编码的
|
||||
* **stringData**：使用 stringData 时，更为方便，您可以直接将取值以明文的方式写在 yaml 文件中
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 解码和编辑Secret
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 解码Secret
|
||||
|
||||
Secret 中的信息可以通过 `kubectl get secret` 命令获取。例如，执行命令 `kubectl get secret mysecret -o yaml
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Secret概述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/)
|
||||
|
||||
## 概述
|
||||
|
||||
@ -9,7 +9,7 @@ meta:
|
||||
|
||||
# 使用Secret存储Ingress TLS证书
|
||||
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
可以直接在 Ingress 中配置 HTTPS 证书，使得你的网站支持 HTTPS 协议。
|
||||
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 概述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： Kubernetes 官网文档 [Taints and Tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)
|
||||
|
||||
Pod 中存在属性 [Node selector / Node affinity](/learning/k8s-intermediate/config/assign-pod-node.html)，用于将 Pod 指定到合适的节点。
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 基于污点的驱逐（TaintBasedEviction）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
在前面的章节中，我们描述了 [NoExecute](/learning/k8s-intermediate/config/taints-toleration/#污点与容忍的匹配) 的污点效果，该效果将对已经运行在节点上的 Pod 施加如下影响：
|
||||
* 不容忍该污点的 Pod 将立刻被驱逐
|
||||
* 容忍该污点的 Pod 在未指定 `tolerationSeconds` 的情况下，将继续在该节点上运行
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 条件化的污点（TaintNodesByCondition）
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
自 Kubernetes 1.12 开始，`TaintNodesByCondition` 这个特性进入 beta 阶段，此时节点控制器自动根据 Node Condition 为节点创建对应的污点。调度器则不去检查 Node conditions，而是检查节点的污点，因此 Node Condition 不再直接影响到调度程序。用户通过为 Pod 添加容忍，可以选择性地忽略节点的某些问题（以 Node Condition 呈现的问题）。
|
||||
|
||||
`TaintNodesByCondition` 这个特性只会为节点添加 `NoSchedule` 效果的污点。`TaintBasedEviction` （Kubernetes 1.13 开始默认生效）则为节点添加 `NoExecute` 效果的污点，参考 [TaintBasedEviction](./taint-based-evictions.html)。
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 使用案例
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
污点和容忍使用起来非常灵活，可以用于：
|
||||
* 避免 Pod 被调度到某些特定的节点
|
||||
* 从节点上驱逐本不应该在该节点运行的 Pod
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 容器的环境变量
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Container Environment Variables](https://kubernetes.io/docs/concepts/containers/container-environment-variables/)
|
||||
|
||||
Kubernetes为容器提供了一系列重要的资源：
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 容器镜像
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
在 Kubernetes 的 Pod 中使用容器镜像之前，您必须将其推送到一个镜像仓库（或者使用仓库中已经有的容器镜像）。在 Kubernetes 的 Pod 定义中定义容器时，必须指定容器所使用的镜像，容器中的 `image` 字段支持与 `docker` 命令一样的语法，包括私有镜像仓库和标签。
|
||||
|
||||
例如：`my-registry.example.com:5000/example/web-example:v1.0.1` 由如下几个部分组成：
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 容器生命周期事件处理
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Attach Handlers to Container Lifecycle Events](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
|
||||
|
||||
Kubernetes 中支持容器的 postStart 和 preStop 事件，本文阐述了如何向容器添加生命周期事件处理程序（handler）。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 容器生命周期
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Container Lifecycle Hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/)
|
||||
|
||||
本文描述了 kubelet 管理的容器如何使用容器生命周期钩子执行指定的代码。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Runtime Class
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
> 参考文档： [Runtime Class](https://kubernetes.io/docs/concepts/containers/runtime-class/)
|
||||
|
||||
特性状态：Kubernetes v1.14 <Badge type="warning">beta</Badge>
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 搭建NFS Server
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 背景
|
||||
|
||||
Kubernetes 对 Pod 进行调度时，以当时集群中各节点的可用资源作为主要依据，自动选择某一个可用的节点，并将 Pod 分配到该节点上。在这种情况下，Pod 中容器数据的持久化如果存储在所在节点的磁盘上，就会产生不可预知的问题，例如，当 Pod 出现故障，Kubernetes 重新调度之后，Pod 所在的新节点上，并不存在上一次 Pod 运行时所在节点上的数据。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 存储卷PersistentVolume
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官方文档 [Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
|
||||
|
||||
## 概述
|
||||
|
||||
@ -8,6 +8,7 @@ meta:
|
||||
|
||||
# 数据卷类型如何选择
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
# 存储卷类型如何选择
|
||||
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 存储类StorageClass
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网 [Storage Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/)
|
||||
|
||||
## 存储类概述
|
||||
|
||||
@ -8,6 +8,8 @@ meta:
|
||||
|
||||
# 数据卷-挂载
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Volumes](https://kubernetes.io/docs/concepts/storage/volumes/)
|
||||
|
||||
## 容器内路径
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 数据卷Volume
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Volumes](https://kubernetes.io/docs/concepts/storage/volumes/)
|
||||
|
||||
## 数据卷概述
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 使用私有仓库中的docker镜像
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
企业通常会因为如下几个原因，需要搭建自己的私有 docker registry：
|
||||
* 限制 docker 镜像的分发范围，例如：只允许在内网分发，或者只允许被授权的用户获取 docker 镜像
|
||||
* 提高推送 docker 镜像以及抓取 docker 镜像时的网络传输速度
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 如何选择网络插件
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文转载自： [kubernetes网络插件对比分析（flannel、calico、weave）](https://www.toutiao.com/a6708893686517727748/)
|
||||
|
||||
原文作者：残花花败柳柳
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Service连接应用程序
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Connecting Applications with Services](https://kubernetes.io/docs/concepts/services-networking/connect-applications-service/)
|
||||
|
||||
## Kubernetes 的网络模型
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Service/Pod的DNS
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档： Kubernetes 官网文档 [DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)
|
||||
|
||||
本文介绍了 Kubernetes 中的 DNS 分配方式
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Ingress通过互联网访问您的应用
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档：
|
||||
* Kubernetes 官网 [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
|
||||
* Kubernetes 官网 [Ingress Controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Service详细描述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档：Kubernetes 官网文档：[Service](https://kubernetes.io/docs/concepts/services-networking/service/)
|
||||
|
||||
## 创建 Service
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 发布Service
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
Kubernetes Service 支持的不同访问方式。
|
||||
|
||||
## Service 类型
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# Service概述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
参考文档：Kubernetes 官网文档：[Service](https://kubernetes.io/docs/concepts/services-networking/service/)
|
||||
|
||||
## 为何需要 Service
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
参考文档： Kubernetes 官网 [Init Containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 初始化容器介绍
|
||||
|
||||
Pod 可以包含多个工作容器，也可以包含一个或多个初始化容器，初始化容器在工作容器启动之前执行。
|
||||
|
||||
@ -7,6 +7,8 @@ meta:
|
||||
|
||||
# 容器组_Kuboard
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 通过 Kuboard 创建容器组
|
||||
|
||||
由于在 Kubernetes 中，任何时候都是不推荐用户直接创建容器组，而是应该通过控制器创建容器组，Kuboard 管理工具并不提供直接创建容器组的界面，而是通过 **工作负载编辑器** 创建 Deployment、StatefulSet、DaemonSet 等方式来创建容器组。
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
参考文档： Kubernetes 官网文档 [Pod Lifecycle](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[[TOC]]
|
||||
|
||||
## Pod phase
|
||||
|
||||
@ -7,6 +7,7 @@ meta:
|
||||
|
||||
# 容器组_Privileged 模式
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## Privilged 模式运行容器
|
||||
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
参考文档：Kubernetes 官方文档 [Pod Overview](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) [Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
术语中英文对照：
|
||||
|
||||
| 英文全称 | 英文缩写 | 中文翻译 |
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
> 参考文档： Kubernetes 官网文档 [Alternatives to DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#alternatives-to-daemonset)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
DaemonSet 有如下替代选项可以选择
|
||||
|
||||
## Init Scripts
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
> 参考文档 Kubernetes 官网文档 [Communicating with Daemon Pods](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#communicating-with-daemon-pods)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
与 DaemonSet 容器组通信的模式有：
|
||||
|
||||
* **Push：** DaemonSet 容器组用来向另一个服务推送信息，例如数据库的统计信息。这种情况下 DaemonSet 容器组没有客户端
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建 DaemonSet
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## YAML 示例
|
||||
|
||||
下面是 DaemonSet 的 YAML 文件示例 daemonset.yaml。该例子中的 DaemonSet 运行了一个 fluentd-elasticsearch 的 docker 镜像：
|
||||
|
||||
@ -11,6 +11,7 @@ meta:
|
||||
|
||||
> 参考文档： Kubernetes 官网文档 [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
DaemonSet 控制器确保所有（或一部分）的节点都运行了一个指定的 Pod 副本。
|
||||
* 每当向集群中添加一个节点时，指定的 Pod 副本也将添加到该节点上
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
> 参考文档 Kubernetes 官网文档 [How Daemon Pods are Scheduled](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#how-daemon-pods-are-scheduled)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 由 DaemonSet 控制器调度
|
||||
|
||||
**v1.12以后默认禁用**
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
> 参考文档 Kubernetes 官网文档 [Updating a DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/#updating-a-daemonset)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 更新信息
|
||||
|
||||
* 在改变节点的标签时：
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 金丝雀发布
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
<el-tabs type="border-card">
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 清理策略
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
通过 Deployment 中 `.spec.revisionHistoryLimit` 字段，可指定为该 Deployment 保留多少个旧的 ReplicaSet。超出该数字的将被在后台进行垃圾回收。该字段的默认值是 10。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 创建 Deployment
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
本文描述了如何创建一个 Deployment，如何理解 Deployment 各个字段，以及如何查看 Deployment 的创建结果。
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
参考文档： Kubernetes 官网 [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)、 [ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
术语表
|
||||
|
||||
| 英文 | 英文简称 | 中文 |
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 暂停和继续 Deployment
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
您可以先暂停 Deployment，然后再触发一个或多个更新，最后再继续（resume）该 Deployment。这种做法使得您可以在暂停和继续中间对 Deployment 做多次更新，而无需触发不必要的滚动更新。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 回滚 Deployment
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
某些情况下，您可能想要回滚（rollback）Deployment，例如：Deployment 不稳定（可能是不断地崩溃）。默认情况下，kubernetes 将保存 Deployment 的所有更新（rollout）历史。您可以设定 revision history limit 来确定保存的历史版本数量。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 伸缩 Deployment
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
伸缩（Scaling） Deployment，是指改变 Deployment 中 Pod 的副本数量，以应对实际业务流量的变化。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 查看 Deployment 的状态
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
Deployment 的生命周期中，将会进入不同的状态，这些状态可能是：
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 更新 Deployment
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 Deployment](./#deployment-概述)
|
||||
|
||||
## 执行更新
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# StatefulSet 的基本信息
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 StatefulSet](./)
|
||||
|
||||
## 创建 StatefulSet
|
||||
|
||||
@ -11,6 +11,8 @@ meta:
|
||||
|
||||
> 参考文档： Kubernetes 官网文档 [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## StatefulSet 概述
|
||||
|
||||
StatefulSet 顾名思义，用于管理 Stateful（有状态）的应用程序。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# StatefulSet 的部署和伸缩
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 StatefulSet](./)
|
||||
|
||||
## 部署和伸缩 StatefulSet 时的执行顺序
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# StatefulSet 的更新策略
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
[返回 StatefulSet](./)
|
||||
|
||||
## StatefulSet 的更新策略 <Badge text="Kuboard 暂不支持" type="warn"/>
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 控制器_概述
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 概述
|
||||
|
||||
Pod（容器组）是 Kubernetes 中最小的调度单元，您可以通过 kubectl 直接创建一个 Pod。Pod 本身并不能自愈（self-healing）。如果一个 Pod 所在的 Node （节点）出现故障，或者调度程序自身出现故障，Pod 将被删除；同理，当因为节点资源不够或节点维护而驱逐 Pod 时，Pod 也将被删除。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 从微服务视角看Kubernetes
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 微服务
|
||||
|
||||
当我们谈论微服务的时候，总避免不了说 Spring Cloud / Dubbo，这些微服务架构的采用，确实达到了我们对他的期许：分布式、熔断/限流、高可用、可扩展、分离关注、链路追踪、小团队快速迭代。
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 在K8S上部署api-gateway
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文假设您已经完成了 [在Kubernetes 上部署 Spring Cloud - OCP](./) 系列教程的前面部分，并已经完成了 eureka-server、api-gateway-mysql、log-center-mysql、redis、auth-server、user-center 在 K8S 上的部署。
|
||||
|
||||
## 理解api-gateway
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 在K8S上部署auth-server
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文假设您已经完成了 [在Kubernetes 上部署 Spring Cloud - OCP](./) 系列教程的前面部分，并已经完成了 eureka-server、auth-center-mysql、redis 在 K8S 上的部署。
|
||||
|
||||
## 理解auth-server
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 在K8S上部署back-center
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文假设您已经完成了 [在Kubernetes 上部署 Spring Cloud - OCP](./) 系列教程的前面部分，并已经完成了 eureka-server、user-center-mysql、log-center-mysql、redis、auth-server、user-center 在 K8S 上的部署。
|
||||
|
||||
## 理解back-center
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 构建docker镜像并推送到仓库
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文假设您已经完成了 [准备OCP的构建环境和部署环境](./prepare.html)，在该文档的最后，我们将 Open Capacity Platform 的代码仓库克隆到了 master 节点的 /root/open-capacity-platform。
|
||||
|
||||
::: tip
|
||||
|
||||
@ -9,6 +9,8 @@ meta:
|
||||
|
||||
# 在K8S上部署eureka-server
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文假设您已经完成了 [在Kubernetes上部署SpringCloud-OCP](/learning/k8s-practice/ocp/) 教程的前序步骤：
|
||||
* [准备OCP的构建环境和部署环境](/learning/k8s-practice/ocp/prepare.html)
|
||||
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 导出部署配置
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
通过本系列文章前面的部分，我们终于完整了 Spring Cloud OCP 的核心组件在 Kubernetes 上的部署。此时，Kuboard 的名称空间 `ocp` 界面的截图如下所示：
|
||||
|
||||
|
||||
|
||||
@ -10,6 +10,8 @@ meta:
|
||||
|
||||
# 导入部署配置
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
<script>
|
||||
|
||||
export default {
|
||||
|
||||
@ -9,6 +9,7 @@ meta:
|
||||
|
||||
# 在Kubernetes上部署SpringCloud
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
## 使用 Kuboard 在 K8S 上部署 OCP
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user