llg___的博客

Unable to connect to the server: x509: certificate has expired or is not yet valid自己服务的pod重启后数量一直会为0。K8S 各个组件需要与 api-server 进行通信，通信使用的证书都存放在 /etc/kubernetes/pki 路径下，由 kubeadm 生成的客户端证书在 1 年后到期，因此需要定时更新证书，否则证书到期会导致整个集群不可用。今天遇到一个k8s证书过期问题，记录下解决方法。

当K8s的Service类型为ClusterIP，不是NodePort，就只能集群内部访问，想在外部访问可以执行kubectl port-forward，将一个或多个本地端口转发到 Pod或者Service。Service就是对提供同一服务的多个pod的聚合，并提供同一的入口地址，因此上面指令中的pod/yourPodName可换成service/youServiceName。原因：没做转发时，这个端口只是开了，并未被监听，此时telnet自然连不上。简单说就是端口开了，但端口下没应用或者服务。指令用法详解

什么是helm?helem常用指令使用K8s部署一个应用，涉及到很种K8s资源的协作，如Deployment 用于部署应用控制pod、Service 提供服务发现、Secret 配置存储用户名和密码，可能还需要 pv 和 pvc 来持久化数据。这么多资源，且过于分散，使用kubectl来进行维护和创建，体验极差。如何统一管理、配置和更新这些分散的 k8s 的应用资源文件如何分发和复用一套应用模板如何将应用的一系列资源当做一个软件包来管理基于以上，helm出现。Helm 是 Kubernetes 的包管理器。

Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是必要的。安全性就是让所有的Kubernetes客户端以一个合法的身份和合法的步骤来访问我们的系统。

以上即pod中busybox容器的的/root目录和pvc建立挂载关系，数据最终持久化到pvc的pv的NFS服务器的目录，即前面初始化NFS时的/root/data/pv1。，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样的话，无论Pod在节点上怎么转移，只要集群Node跟NFS的对接没问题，数据就可以成功访问。主要用于存储敏感信息，例如密码、秘钥、证书等等。程序运行在容器中，而容器的生命周期可能极其短暂，容器销毁，数据丢失，因此，为了持久化容器中的数据，Volumn出现。

上一章中，NotePort和LoadBalancer类型的Service可给集群外部机器提供访问，但这两种类型都有缺点：由此，Ingress资源对象出现，Ingress或者一个LB就可以满足暴露多个Service的需求。总结就是ingress中定义转发规则，ingress controller中解析规则，完成转发Ingress（以Nginx为例）的工作原理如下：下载ingress的yaml文件：创建ingress-nginx的pod和Service创建pod和Service，结构如下：使用- - -把

程序在容器中、容器在Pod中，可以通过pod的ip来访问应用程序，但是podIP会随着创建销毁而改变。由此，Service出现：Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。在整个Service的生命周期中，ServiceIP是不会变化的。Service是一个概念，真正起作用的是kube-proxy服务进程：每个Node节点上都运行着一个kube-proxy服务进程。

自主式pod：kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建控制器创建的pod：kubernetes通过控制器创建的pod，这种pod删除了之后还会自动重建Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod。

每个Pod中都可以包含一个或者多个容器，这些容器可以分为两类：1）用户容器：用户程序所在的容器，数量可多可少2）根容器可以以它为依据，评估整个Pod的健康状态可以在根容器上设置Ip地址，其它容器都共享此Ip（Pod IP），以实现Pod内部的网络通信注意上面说的是Pod内部的通讯，Pod的之间的通讯采用虚拟二层网络技术来实现，我们当前环境用的是Flannel下面是Pod的资源清单：（常用的）

在kubernetes中，所有的内容都抽象为资源，用户需要通过操作资源来管理kubernetes。kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务，所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。kubernetes的最小管理单元是pod而不是容器，所以只能将容器放在Pod中，而kubernetes一般也不会直接管理Pod，而是通过Pod控制器来管理Pod的。

传统部署：互联网早期，会直接将应用程序部署在物理机上优点：简单，不需要其它技术的参与缺点：不能为应用程序定义资源使用边界，很难合理地分配计算资源，而且程序之间容易产生影响虚拟化部署：可以在一台物理机上运行多个虚拟机，每个虚拟机都是独立的一个环境优点：程序环境不会相互产生影响，提供了一定程度的安全性缺点：增加了操作系统，浪费了部分资源容器化部署：与虚拟化类似，但是共享了操作系统优点：可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等。