Songyaxuan075118的博客

可以使用命令：mv chart.yaml Chart.yaml。由于已使用同样镜像发布了pod，导致无节点可调度。删除所有 pod 后部署 pod 即可。

安装 promethus 监控组件即可。在 nfs 卷中创建文件并授予权限。nfs 卷中没有文件或权限不对。没有 heapster 服务。

accessModes 与可使用的 PV 不一致，导致无法挂载 PVC，由于只能挂载大于 1G 且 accessModes为 RWO 的 PV；故只能成功创建 1 个 pod，第 2 个 pod 一致 pending，按序创建时则第 3 个 pod 一直未被创建。修改 yaml 文件中 accessModes 或 PV 的 accessModes 即可。修改 pv 的 name 字段即可。pv 的 name 字段重复。pod 无法挂载 PVC。

K8S 创建服务 status 为 ErrlmagePull？不能进入指定容器内部？上面两个问题的原因分析与解决方法。

pod 创建失败？kube-flannel-ds-amd64-ndsf7 插件 pod 的 status 为 Init:0/1 ？以上问题的原因分析及解决方法

pod 创建失败？pod 的 ready 状态未进入？以上问题的原因分析及解决办法

创建 init C 容器后，其状态不正常原因分析及解决方法

pod 状态为 ErrlmagePull 的原因分析及解决方法探测存活 pod 状态为 CrashLoopBackOff 的原因分析及解决方法

K8S 集群服务暴露失败：- 原因分析：该容器已暴露服务了。- 解决方法：删除 svc，重新映射端口即可。外网无法访问 K8S 集群提供的服务：- 原因分析：K8S 集群的 type 为 ClusterlP，未将服务暴露至外网。- 解决方法：修改K8S 集群的 type 为 NodePort 即可，于是可通过所有 K8S 集群节点访问服务。

K8S 集群服务访问失败- 原因分析：证书不能被识别- 其原因为：自定义证书，过期等- 原因分析：端口映射错误，服务正常工作，但不能提供服务

- 该公司可以使用 Docker 环境，组成一个跨部门团队，以使用 Kubernetes 构建 Web 应用程序。- 这种框架将帮助公司实现在最短时间内将所需物品投入生产的目标。- 因此，通过运行这种机器，公司可以向所有具有各种环境的客户提供帮助。- 该公司可以将其基础架构分解为微服务，然后采用 Kubernetes。- 这将使公司在不同的云基础架构上运行各种工作负载。

- Kubernetes 确保有效地优化资源，并且仅使用特定应用程序所需的那些资源。- 因此，通过使用最佳的容器编排工具，公司可以有效地实现资源分配。- 一旦将所有应用程序部署到容器中，他们就可以使用 Kubernetes 进行编排，并使用 Prometheus 等容器监视工具来监视容器中的动作。- 因此，使用这样的容器，可以为它们提供更好的数据中心容量规划，因为由于服务和运行的硬件之间的这种抽象，它们现在将具有更少的约束。

- 要解决该问题，他们可以将其整体代码库转移到微服务设计中，然后将每个微服务都视为一个容器。- 因此，所有这些容器都可以在Kubernetes的帮助下进行部署和编排。- 该团队可以尝试使用容器编排平台（例如Kubernetes）并在数据中心中运行它。- 因此，借助此工具，该公司可以生成模板化的应用程序，在五分钟内对其进行部署，并在此时将实际实例包含在登台环境中。- 这种Kubernetes项目将具有数十个并行运行的微服务，以提高生产率，即使节点发生故障，也可以立即对其进行重新调度，而不会影响性能。

- 因此，在实施 CI /CD 管道之后，公司的下一步应该是在云环境中工作。- 一旦他们开始在云环境中工作，他们就可以在集群上调度容器，并可以在 Kubernetes 的帮助下进行编排。- 现在，要做到这一点，公司应该从其私有数据中心（如果他们使用的是任何数据中心）迁移到任何云环境（例如 AWS）。- 不仅如此，他们还应该实现微服务架构，以便他们可以开始使用 Docker 容器。- 一旦他们准备好了基础框架，便可以开始使用可用的最佳编排平台，即 Kubernetes。

- 一步一步地并行构建，而只需在后台切换配置即可。- 然后，他们可以将每个内置微服务放在 Kubernetes 平台上。- 因此，他们可以从迁移服务一次或两次并监视它们以确保一切运行稳定开始。- 一旦他们感觉一切顺利，就可以将应用程序的其余部分迁移到其 Kubernetes 集群中。- 使用能够为基于云的应用程序提供敏捷性，横向扩展功能和 DevOps 实践的功能。- 因此，该公司可以使用 Kubernetes 定制其调度架构并支持多种容器格式。

使用 Kubernetes 时可以采取的最佳安全措施借助联合集群，可以将多个 Kubernetes 集群作为一个集群进行管理。因此，您可以在一个数据中心 / 云中创建多个 Kubernetes 集群，并使用联合在一个地方控制/管理所有集群。联合群集可以通过执行两项操作来实现此目的

对于用户而言，了解所有不同抽象层的应用程序性能和资源利用率非常重要 Kubernetes 通过在不同级别（例如容器，pod，服务和整个集群）创建抽象，从而对集群的管理进行了分解。副本集和复制控制器执行几乎相同的操作。它们两者都确保在任何给定时间都运行指定数量的 Pod 副本。不同之处在于使用选择器来复制容器。副本集使用基于集合的选择器，而复制控制器使用基于权益的选择器基于股权的选择器：这种类型的选择器允许按标签键和值进行过滤。基于选择器的选择器：这种类型的选择器允许根据一组值过滤键。

kube-apiserver 和 kube-scheduler 的作用Cloud Controller Manager 负责持久性存储，网络路由，从核心 Kubernetes 特定代码中提取特定于云的代码以及管理与基础云服务的通信。

Kubernetes 架构主要包含两个组件：主节点和工作节点。主节点和工作节点中有许多内置组件。主节点具有 kube-controller-manager，kube-apiserver，kube-scheduler 等。而工作程序节点在每个节点上都运行 kubelet 和 kube-proxy。Kubernetes 主节点控制节点，并且在节点内部存在容器。现在，这些单独的容器包含在 Pod 内，每个 Pod 内您可以根据配置和要求拥有各种数量的容器。

iptables 四个表iptables 五个链由于典型的应用程序具有跨多个主机运行的容器集群，因此所有这些容器都需要相互通信。平衡负载，缩放和监视容器由于 Kubernetes 与云无关，并且可以在任何公共 / 私有提供商上运行，因此必须选择简化容器化部署。

kubelet 进程用于处理 master 下发的任务，管理 pod 中的容器，注册自身所在的节点。kube-proxy 本质上类似一个反向代理。我们可以把每个节点上运行的 kube-proxy 看作 service 的透明代理兼 LB。Service 是 k8s 中资源的一种，也是 k8s 能够实现减少运维工作量，甚至免运维的关键。kube-proxy 的流量代理，一共有三种模式：userspace、iptables 以及 ipvs。

k8s 上面会跑大量的 pod / 容器。 特别是集群相关的控制面容器，业务容器，有时候我们要对容器日志进行监控与分析处理，这时一套好用的日志系统就格外的重要。以前的 ELK，k8s 主推的基于云原生的 EFK，这里的 F 是 CNCF 认证的子项目 fluentd，fluentd 是 ruby 的项目，由于个人体验习惯与 yaml 配置，以及项目特点，选择了 filebeat ，所以整套日志系统使用的技术包括（elastic search fidlebeat kibana）。

Docker 的 4 种网络通信模式：1、host 模式：- host 模式，使用 --net=host 指定。2、container 模式：- container 模式，使用 --net=container:NAMEorID 指定。3、none 模式：- none 模式，使用 --net=none 指定。4、bridge 模式：- bridge 模式，使用 --net=bridge 指定，默认设置。

Jenkins Pipeline 中脚本语法中的几个关键字。pipeline 是 jenkins2.X 最核心的特性。pipeline 提供一组可扩展的工具。为什么要使用 pipeline？块（Blocks{}）章节（Sections）指令（Directives）步骤（steps）

Pod 启动失败的原因K8s 中 label 的几种应用场景用来传递用户定义的属性通过 Label（tier=frontendapp=myapp）来标记前端 Pod 容器，使用 Label（tier=backend，app=myapp）标记后台 Pod。

存活性探针（liveness probes）就绪性探针（readiness probes）主要的探测方式支持 http 探测，执行命令探测，以及 tcp 探测探测失败的可能原因：容器未成功启动，或者执行命令失败docker 或者 docker-shim 存在故障从 node 到容器 ip 的网络不通

特殊的 Pause 容器namespace 命名空间unshare：pause container 作为 pod 里其他所有 container 的 parent container，主要有两个职责：① 是 pod 里其他容器共享 Linux namespace 的基础；② 扮演 PID 1 的角色，负责处理僵尸进程。

kube-proxy 的三种工作模式和原理userspace 模式iptables 模式ipvs 模式

Scheduler 工作原理节点预选（Predicate）节点优先级排序（Priority）节点择优（Select）k8s 的调度步骤k8s 的调用工作方式可压缩资源不可压缩资源

deployment（适合无状态的服务部署）Statefulset（适合有状态的服务部署​​​​​​​）Daemonset（一次部署）Job（一次性的执行任务）Cronjob（周期性的执行任务）ingress-controller 的工作机制Ingress

节点宕机生命周期控制器：node lifecycle_controller.go Unknown 状态的节点上已经运行的 pod 的处理方式。污点管理器（taint_manager.go）容忍度当到了删除 Pod 时，污点管理器会创建污点标记事件，然后驱逐 pod 。资源控制器（Controller）deployment 控制器Statefulset 控制器

calicocalico 的工作原理FlannelFlannel 的工作原理calico 根据 iptables 规则进行路由转发，并没有进行封包，解包的过程，这和 flannel 比起来效率就会快多。Flannel 实质上是一种 “ 覆盖网络（overlay network）” ，也就是将 TCP 数据包装在另一种网络包里面进行路由转发和通信，目前已经支持 UDP、VxLAN、AWS VPC 和 GCE 路由等数据转发方式。

Kubernetes 平台Kubernetes 集群Headless Service没有群集 IP

Kubernetes在不同的云基础架构上运行各种工作负载Google 容器引擎

集装箱化使用 Kubernetes 进行编排使用像 Prometheus 这样的容器监视工具来监视容器中的操作使用 Docker 环境，组建一个横截面团队，使用 Kubernetes 构建 Web 应用程序。

容器编排平台Kubernetes即使节点出现故障，也可以立即重新安排，而不会影响性能。扩展平台来增加服务器数量Kubernetes 可以确保资源得到有效优化，并且只使用特定应用程序所需的那些资源。

公司应该从他们的私有数据中心（如果他们使用任何）转移到任何云环境，如 AWS。他们还应该实现微服务架构，以便他们可以开始使用 Docker 容器。一旦他们准备好基础框架，他们就可以开始使用最好的编排平台，即 Kubernetes。所有这些容器都可以在 Kubernetes 的帮助下进行部署和协调。

Kubernetes 来定制他们的调度架构并支持多种容器格式通过构建 CI/CD 管道来实现 DevOps 方法

HelmHelm的优势Helm的针对性特点

EFK 实现日志的统一管理ElasticsearchFluentdKibana进行优雅的节点关机维护集群联邦