K8s部分概念
K8s部分概念
Kubernetes核心组件
| 组件名称 | 说明 |
|---|---|
| etcd | 保存了整个集群的状态 |
| apiserver | 提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制 |
| controller manager | 负责维护集群的状态，比如故障监测、自动拓展、滚动更新等 |
| scheduler | 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上 |
| kubelet | 负责维护容器的生命周期，同时也负责Volume(CVI)和网络(CNI)的管理 |
| container runtime | 负责镜像管理以及Pod和容器的真正运行(CRI) |
| kube-proxy | 负责为Service提供cluster内部的服务发现和负载均衡 |
Kubernetes拓展组件
| 组件名称 | 说明 |
|---|---|
| kube-dns | 负责为整个集群提供DNS服务 |
| ingress controller | 负责为服务提供外网接口 |
| heapster | 提供资源监控 |
| dashboard | 提供GUI |
| federation | 提供跨可用区的集群 |
| fluentd-elasticsearch | 提供集群日志采集、存储和查询 |
Kubernetes 的 11 个部分(转)
1. Pod
Pod 是 Kubernetes 中最小的可互动单元。一个 Pod 可以由多个容器组成，这些容器共同部署在单个节点上形成一个单元。一个 Pod 具有一个 IP，该 IP 在其容器之间共享。
在微服务世界中，一个 Pod 可以是执行后台工作或服务请求的微服务的单个实例。
2. Node（节点）
Node 是机器。它们是 Kubernetes 用于部署 Pod 的“裸机”（或虚拟机）。Node 为 Kubernetes 提供可用的集群资源用于以保持数据、运行作业、维护工作负载、创建网络路由等。
3. Label（标签）与 Annotation（注解）
Label 是 Kubernetes 及其最终用户用于过滤系统中相似资源的方式，也是资源与资源相互“访问”或关联的粘合剂。比如说，为 Deployment 打开端口的 Service。不论是监控、日志、调试或是测试，任何 Kubernetes 资源都应打上标签以供后续查验。例如，给系统中所有 Worker Pod 打上标签：app=worker，之后即可在 kubectl 或 Kubernetes API 中使用 --selector 字段对其进行选择。
Annotation 与 Label 非常相似，但通常用于以自由的字符串形式保存不同对象的元数据，例如“更改原因: 安全补丁升级”。
4. Service Discovery（服务发现）
作为编排系统，Kubernetes 控制着不同工作负载的众多资源，负责管理 Pod、作业及所有需要通信的物理资源的网络。为此，Kubernetes 使用了 ETCD。
ETCD 是 Kubernetes 的“内部”数据库，Master 通过它来获取所有资源的位置。Kubernetes 还为服务提供了实际的“服务发现”——所有 Pod 使用了一个自定义的 DNS 服务器，通过解析其他服务的名称以获取其 IP 地址和端口。它在 Kubernetes 集群中“开箱即用”，无须进行设置。
5. ReplicaSet（副本集）
虽然 Pod 是一个物理性的运行任务，但通常使用单个实例是不够的。为了冗余并处理负载，出于某种原因（比如“伸缩”）需要对 Pod 进行复制。为了实现负责扩展和复制的层，Kubernetes 使用了 ReplicaSet。这个层以副本的数量表示系统的期望状态，并在任意给定时刻保持该系统的当前状态。
这也是配置自动伸缩的所在，在系统高负载时创建额外的副本，并在不再需要这些资源来支撑所运行的工作负载时进行缩容。
6. DaemonSet（守护进程集）
有时候，应用程序每个节点需要的实例不超过一个。比如 FileBeat 这类日志收集器就是个很好的例子。为了从各个节点收集日志，其代理需要运行在所有节点上，但每个节点只需要一个实例。Kubernetes 的 DaemonSet 即可用于创建这样的工作负载。
7. StatefulSet（有状态集）
尽管多数微服务涉及的都是不可变的无状态应用程序，但也有例外。有状态的工作负载有赖于磁盘卷的可靠支持。虽然应用程序容器本身可以是不可变的，可以使用更新的版本或更健康的实例来替代，但是所有副本还是需要数据的持久化。StatefulSet 即是用于这类需要在整个生命周期内使用同一节点的应用程序的部署。
它还保留了它的“名称”：容器内的 hostname 以及整个集群中服务发现的名称。3 个 ZooKeeper 构成的 StatefulSet 可以被命名 zk-1、zk-2 及 zk-3，也可以扩展到更多的成员 zk-4、zk-5 等等…… StatefulSets 还负责管理 PersistentVolumeClaim（Pod 上连接的磁盘）。
8. Job（任务）
Kubernetes 核心团队考虑了大部分使用编排系统的应用程序。虽然多数应用程序要求持续运行以同时处理服务器请求（比如 Web 服务器），但有时还是需要生成一批作业并在其完成后进行清理。比如，一个迷你的无服务器环境。
为了在 Kubernetes 中实现这一点，可以使用 Job 资源。正如其名，Job 的工作是生成容器来完成特定的工作，并在成功完成时销毁。举个例子，一组 Worker 从待处理和存储的数据队列中读取作业。一旦队列空了，就不再需要这些 Worker 了，直到下个批次准备好。
9. ConfigMap（配置映射）及 Secret（机密配置）
如果你还不熟悉十二要素应用清单，请先行了解。现代应用程序的一个关键概念是无环境，并可通过注入的环境变量进行配置。应用程序应与其位置完全无关。为了在 Kubernetes 中实现这个重要的概念，就有了 ConfigMap。实际上这是一个环境变量键值列表，它们会被传递给正在运行的工作负载以确定不同的运行时行为。在同样的范畴下，Secret 与正常的配置条目类似，只是会进行加密以防类似密钥、密码、证书等敏感信息的泄漏。
10. Deployment（部署）
一切看起来都很美好，Pod 可以正常运行，如果上层有 ReplicaSet，还可以根据负载进行伸缩。不过，大家蜂拥而来，为的是能用新版本快速替换应用程序。我们想小规模地进行构建、测试和发布，以缩短反馈周期。使用 Deployments 即可持续地部署新软件，这是一组描述特定运行工作负载新需求的元数据。举个例子，发布新版本、错误修复，甚至是回滚（这是 Kubernetes 的另一个内部选项）。
在 Kubernetes 中部署软件可使用 2 个主要策略：
- 替换——正如其名，使用新需求替换全部负载，自然会强制停机。对于快速替换非生产环境的资源，这很有帮助。
- 滚动升级——通过监听两个特定配置慢慢地将容器替换成新的：
MaxAvailable——设置在部署新版本时可用的工作负载比例（或具体数量），100% 表示“我有 2 个容器，在部署时要保持 2 个存活以服务请求”；b. MaxSurge——设置在当前存活容器的基础上部署的工作负载比例（或数量），100% 表示“我有 X 个容器，部署另外 X 个容器，然后开始滚动移除旧容器”。
11. Storage（存储）
Kubernetes 在存储之上添加了一层抽象。工作负载可以为不同任务请求特定存储，甚至可以管理超过 Pod 生命周期的持久化。
操作
pod
kubectl create -f xxx.yaml
kubectl get pods
kubectl desctibe pod xxxx
kubectl delete pod xxx --force --grace-period=0#(强制删除)
kubectl apply
其余资料
强烈推荐k8s官方的中文文档，看官方文档才是最好的方式
K8s知识点
Kubernetes核心组件
| 组件名称 | 说明 |
|---|---|
| etcd | 保存了整个集群的状态 |
| apiserver | 提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制 |
| controller manager | 负责维护集群的状态，比如故障监测、自动拓展、滚动更新等 |
| scheduler | 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上 |
| kubelet | 负责维护容器的生命周期，同时也负责Volume(CVI)和网络(CNI)的管理 |
| container runtime | 负责镜像管理以及Pod和容器的真正运行(CRI) |
| kube-proxy | 负责为Service提供cluster内部的服务发现和负载均衡 |
Kubernetes拓展组件
| 组件名称 | 说明 |
|---|---|
| kube-dns | 负责为整个集群提供DNS服务 |
| ingress controller | 负责为服务提供外网接口 |
| heapster | 提供资源监控 |
| dashboard | 提供GUI |
| federation | 提供跨可用区的集群 |
| fluentd-elasticsearch | 提供集群日志采集、存储和查询 |
Kubernetes 的 11 个部分(转)
1. Pod
Pod 是 Kubernetes 中最小的可互动单元。一个 Pod 可以由多个容器组成，这些容器共同部署在单个节点上形成一个单元。一个 Pod 具有一个 IP，该 IP 在其容器之间共享。
在微服务世界中，一个 Pod 可以是执行后台工作或服务请求的微服务的单个实例。
2. Node（节点）
Node 是机器。它们是 Kubernetes 用于部署 Pod 的“裸机”（或虚拟机）。Node 为 Kubernetes 提供可用的集群资源用于以保持数据、运行作业、维护工作负载、创建网络路由等。
3. Label（标签）与 Annotation（注解）
Label 是 Kubernetes 及其最终用户用于过滤系统中相似资源的方式，也是资源与资源相互“访问”或关联的粘合剂。比如说，为 Deployment 打开端口的 Service。不论是监控、日志、调试或是测试，任何 Kubernetes 资源都应打上标签以供后续查验。例如，给系统中所有 Worker Pod 打上标签：app=worker，之后即可在 kubectl 或 Kubernetes API 中使用 --selector 字段对其进行选择。
Annotation 与 Label 非常相似，但通常用于以自由的字符串形式保存不同对象的元数据，例如“更改原因: 安全补丁升级”。
4. Service Discovery（服务发现）
作为编排系统，Kubernetes 控制着不同工作负载的众多资源，负责管理 Pod、作业及所有需要通信的物理资源的网络。为此，Kubernetes 使用了 ETCD。
ETCD 是 Kubernetes 的“内部”数据库，Master 通过它来获取所有资源的位置。Kubernetes 还为服务提供了实际的“服务发现”——所有 Pod 使用了一个自定义的 DNS 服务器，通过解析其他服务的名称以获取其 IP 地址和端口。它在 Kubernetes 集群中“开箱即用”，无须进行设置。
5. ReplicaSet（副本集）
虽然 Pod 是一个物理性的运行任务，但通常使用单个实例是不够的。为了冗余并处理负载，出于某种原因（比如“伸缩”）需要对 Pod 进行复制。为了实现负责扩展和复制的层，Kubernetes 使用了 ReplicaSet。这个层以副本的数量表示系统的期望状态，并在任意给定时刻保持该系统的当前状态。
这也是配置自动伸缩的所在，在系统高负载时创建额外的副本，并在不再需要这些资源来支撑所运行的工作负载时进行缩容。
6. DaemonSet（守护进程集）
有时候，应用程序每个节点需要的实例不超过一个。比如 FileBeat 这类日志收集器就是个很好的例子。为了从各个节点收集日志，其代理需要运行在所有节点上，但每个节点只需要一个实例。Kubernetes 的 DaemonSet 即可用于创建这样的工作负载。
7. StatefulSet（有状态集）
尽管多数微服务涉及的都是不可变的无状态应用程序，但也有例外。有状态的工作负载有赖于磁盘卷的可靠支持。虽然应用程序容器本身可以是不可变的，可以使用更新的版本或更健康的实例来替代，但是所有副本还是需要数据的持久化。StatefulSet 即是用于这类需要在整个生命周期内使用同一节点的应用程序的部署。
它还保留了它的“名称”：容器内的 hostname 以及整个集群中服务发现的名称。3 个 ZooKeeper 构成的 StatefulSet 可以被命名 zk-1、zk-2 及 zk-3，也可以扩展到更多的成员 zk-4、zk-5 等等…… StatefulSets 还负责管理 PersistentVolumeClaim（Pod 上连接的磁盘）。
8. Job（任务）
Kubernetes 核心团队考虑了大部分使用编排系统的应用程序。虽然多数应用程序要求持续运行以同时处理服务器请求（比如 Web 服务器），但有时还是需要生成一批作业并在其完成后进行清理。比如，一个迷你的无服务器环境。
为了在 Kubernetes 中实现这一点，可以使用 Job 资源。正如其名，Job 的工作是生成容器来完成特定的工作，并在成功完成时销毁。举个例子，一组 Worker 从待处理和存储的数据队列中读取作业。一旦队列空了，就不再需要这些 Worker 了，直到下个批次准备好。
9. ConfigMap（配置映射）及 Secret（机密配置）
如果你还不熟悉十二要素应用清单，请先行了解。现代应用程序的一个关键概念是无环境，并可通过注入的环境变量进行配置。应用程序应与其位置完全无关。为了在 Kubernetes 中实现这个重要的概念，就有了 ConfigMap。实际上这是一个环境变量键值列表，它们会被传递给正在运行的工作负载以确定不同的运行时行为。在同样的范畴下，Secret 与正常的配置条目类似，只是会进行加密以防类似密钥、密码、证书等敏感信息的泄漏。
10. Deployment（部署）
一切看起来都很美好，Pod 可以正常运行，如果上层有 ReplicaSet，还可以根据负载进行伸缩。不过，大家蜂拥而来，为的是能用新版本快速替换应用程序。我们想小规模地进行构建、测试和发布，以缩短反馈周期。使用 Deployments 即可持续地部署新软件，这是一组描述特定运行工作负载新需求的元数据。举个例子，发布新版本、错误修复，甚至是回滚（这是 Kubernetes 的另一个内部选项）。
在 Kubernetes 中部署软件可使用 2 个主要策略：
- 替换——正如其名，使用新需求替换全部负载，自然会强制停机。对于快速替换非生产环境的资源，这很有帮助。
- 滚动升级——通过监听两个特定配置慢慢地将容器替换成新的：
MaxAvailable——设置在部署新版本时可用的工作负载比例（或具体数量），100% 表示“我有 2 个容器，在部署时要保持 2 个存活以服务请求”；b. MaxSurge——设置在当前存活容器的基础上部署的工作负载比例（或数量），100% 表示“我有 X 个容器，部署另外 X 个容器，然后开始滚动移除旧容器”。
11. Storage（存储）
Kubernetes 在存储之上添加了一层抽象。工作负载可以为不同任务请求特定存储，甚至可以管理超过 Pod 生命周期的持久化。
操作
pod
kubectl create -f xxx.yaml
kubectl get pods
kubectl desctibe pod xxxx
kubectl delete pod xxx --force --grace-period=0#(强制删除)
kubectl apply
