pod

Kubernetes的概述 Kubernetes是一个开源的Docker容器编排系统，Kubernetes简称K8S。 调度计算集群的节点，动态管理上面的作业 通过使用[labels]和[pods]的概念，将应用按逻辑单元进行分组 K8S用于容器应用程序的部署，扩展和管理 K8S提供了容器编排，资源调度，弹性伸缩，部署管理，服务发现等一系列功能 Kubernetes目标是让部署容器化应运简单高效 官方网站： http://www.kubernetes.io Kubernetes的特性 自我修复： 在节点故障时重新启动失败的容器，替换和重新部署，保证预测的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。 弹性伸缩： 使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务 自动部署和回滚： K8S采用滚动更新应用，一次更新一个Pod，而不是同时删除所有Pod，如果更新过程中出现问题，将回滚更改，确保升级不受影响业务 服务发现和负载均衡： K8S为多个容器提供一个统一的访问入口（内部IP地址和UI个DNS地址），并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题 机密和配置管理： 管理机密数据和应用程序配置。而不需要把敏感数据暴露在镜像里

博文大纲： 一、Ingress简介 1）Ingress组成 2）Ingress工作原理 3） Ingress可以解决什么问题？ 二、配置Ingress-nginx 1）搭建registry私有仓库 2）创建用于测试的Pod 2）创建tomcat服务及其service 3）确保以上资源对象成功创建 4）创建Ingress-controller资源对象 5）创建Ingress资源对象 6）为Ingress-controller资源对象创建一个service资源对象 7）创建基于虚拟主机的Ingress规则 三、配置HTTPS 一、Ingress简介 在Kubernetes中，服务和Pod的IP地址仅在集群内部网络内部使用，对于集群的应用是不可见的。 为了使外部的应用能够访问集群内的服务，在Kubernetes目前提供了以下几种方案： 1）NodePort 2）LoadBalancer 3）Ingress 1）Ingress组成 Ingress 是反向代理规则，用来规定 HTTP/S 请求应该被转发到哪个 Service 上，比如根据请求中不同的 Host 和 url 路径让请求落到不同的 Service 上； Ingress Controller 就是一个反向代理程序，它负责解析 Ingress 的反向代理规则，如果 Ingress 有增删改的变动，所有的 Ingress

k8s数据持久化 Docker容器是有生命周期的，因此数据卷可以实现数据持久化 数据卷主要解决的问题： 数据持久性：当我们写入数据时，文件都是暂时性的存在，当容器崩溃后，host就会将这个容器杀死，然后重新从镜像创建容器，数据就会丢失 数据共享：在同一个Pod中运行容器，会存在共享文件的需求 存储类 （Storage class）是k8s资源类型的一种，它是有管理员为管理PV更加方便创建的一个逻辑组，可以按照存储系统的性能高低，或者综合服务质量，备份策略等分类。不过k8s本身不知道类别到底是什么，它这是作为一个描述。 存储类的好处之一就是支持PV的动态创建，当用户用到持久性存储时，不必再去提前创建PV，而是直接创建PVC就可以了，非常的方便。 存储类对象的名称很重要，并且出了名称之外，还有3个关键字段 Provisioner（供给方）: 及提供了存储资源的存储系统。k8s内建有多重供给方，这些供给方的名字都以“kubernetes.io”为前缀。并且还可以自定义。 Parameters(参数)：存储类使用参数描述要关联到的存储卷，注意不同的供给方参数也不同。 reclaimPolicy:PV的回收策略，可用值有Delete(默认)和Retain Volume： emptyDir（空目录）： 使用情况比较少，一般只做临时使用，类似Docker数据 持久化的：docker

一、Secret Secret :用来保存一些敏感信息，比如数据库的用户名密码或者秘钥。 概览 Secret是用来保存小片敏感数据的k8s资源，例如密码，token，或者秘钥。这类数据当然也可以存放在Pod或者镜像中，但是放在Secret中是为了更方便的控制如何使用数据，并减少暴露的风险。 用户可以创建自己的secret，系统也会有自己的secret。 Pod需要先引用才能使用某个secret，Pod有2种方式来使用secret：作为volume的一个域被一个或多个容器挂载；在拉取镜像的时候被kubelet引用。 內建的Secrets 由ServiceAccount创建的API证书附加的秘钥 k8s自动生成的用来访问apiserver的Secret，所有Pod会默认使用这个Secret与apiserver通信 1. Secret类型 Secret有三种类型： Opaque：使用base64编码存储信息，可以通过base64 --decode解码获得原始数据，因此安全性弱。 kubernetes.io/dockerconfigjson：用于存储docker registry的认证信息。 kubernetes.io/service-account-token：用于被 serviceaccount 引用。serviceaccout 创建时 Kubernetes 会默认创建对应的

1、Master组件 ●kube-apiserver Kubernetes API,集群的统一入口，各组件协调者，以RESTful API提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。 ●kube-controller-manager 处理集群中常规后台任务，一个 资源对应一个控制 器，而ControllerManager就是负责管理这些控制器的。 ●kube-scheduler 根据调度算法为新创建的Pod选择一个Node节点，可以任意部署，可以部署在同一个节点上，也可以部署在不同的节点上。 ●etcd 分布式键值存储系统。用于保存集群状态数据，比如Pod、Service 等对象信息。 2、Node组件 ●kubelet kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下 载secret、获取容器和节点状态等工作。kubelet将 每个Pod转换成一组容器。 ●kube-proxy 在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。 ●docker或rocket 容器引擎，运行容器。 工作原理： 1、准备包含应用程序的Deployment的yml文件，然后通过kubectl客户端工具发送给ApiServer。 2

系统日志 Feb 25 14:20:31 ubuntu systemd[1]: Started libcontainer container 15b23c11b8fee60349fd84e928d04d6fd26b9f04c0aadbc5aebde97d77765c8f. Feb 25 14:20:31 ubuntu kernel: [166679.978936] IPVS: Creating netns size=2200 id=10507 Feb 25 14:20:31 ubuntu kubelet[32051]: W0225 14:20:31.532551 32051 docker_sandbox.go:394] failed to read pod IP from plugin/docker: networkPlugin cni failed on the status hook for pod "coredns-6955765f44-5mbc5_kube-system": CNI failed to retrieve network namespace path: cannot find network namespace for the terminated container

一、 Secret资源对象：解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用。 用来保存一些敏感信息，比如数据库的用户名密码或者密钥。 Secret有三种类型： 1.Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中。 2.Opaque：base64编码格式的Secret，用来存储密码、密钥等。 3.Kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。 二，以实验测试的方式，创建4种secret资源。 姓名：class=lbs 密码：password=www.com 创建2个Pod，分别以挂载Volume的方式，和以环境变量env的方式去使用,secret2，和secret4. 1）通过 --from-literal（文字的）： kubectl create secret generic **lbssecret1 （创建secret资源的名）**--from-literal=class=lbs --from-literal=password=www

背景 测试的时候，通常需要将 Pod 中的 container 频繁地杀死，重启。在这个过程中，Pod 的状态经常会出现 CrashLoopBackOff，而且 container 重启的时间越来越长。 分析 为了避免 container 频繁地 restart，k8s 对 container restart 过程做了限制，使用 back-off 的方法，官方文档中的说法是： Failed containers that are restarted by Kubelet, are restarted with an exponential back-off delay, the delay is in multiples of sync-frequency 0, 1x, 2x, 4x, 8x … capped at 5 minutes and is reset after 10 minutes of successful execution. https://kubernetes-v1-4.github.io/docs/user-guide/pod-states/ 这里先直接给出结论： 在 Pod 中 restart container 的时候（具体时机是，周期性执行 SyncPod() 的时候），Pod 会通过自身的 Status 结构找到当前这个 container（因为

资源限制 pod和container的资源请求和限制 #cpu上限 spec.containers[].resources.limits.cpu #内存上限 spec.containers[].resources.limits.memory #创建时分配的基本cpu资源 spec.containers[].resources.requests.cpu #创建时分配的基本内存资源 spec.containers[].resources.requests.memory 示例演示（在master1端操作） 创建pod2.yaml文件 vim pod2.yaml apiVersion: v1 kind: Pod metadata: name: frontend #Pod资源的名称 spec: containers: - name: db #容器1的名称 image: mysql env: - name: MYSQL_ROOT_PASSWORD value: "password" resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" - name: wp #容器2的名称 image: wordpress resources: requests: memory: "64Mi"

一、Ingress 及 Ingress Controller 简介 Ingress简单的理解: 原先暴露的service,现在给定个统一的访问入口。 Ingress 是 k8s 资源对象，用于对外暴露服务，该资源对象定义了不同主机名（域名）及 URL 和对应后端 Service（k8s Service）的绑定，根据不同的路径路由 http 和 https 流量。而 Ingress Contoller 是一个 pod 服务，封装了一个 web 前端负载均衡器，同时在其基础上实现了动态感知 Ingress 并根据 Ingress 的定义动态生成 前端 web 负载均衡器的配置文件，比如 Nginx Ingress Controller 本质上就是一个 Nginx，只不过它能根据 Ingress 资源的定义动态生成 Nginx 的配置文件，然后动态 Reload。个人觉得 Ingress Controller 的重大作用是将前端负载均衡器和 Kubernetes 完美地结合了起来，一方面在云、容器平台下方便配置的管理，另一方面实现了集群统一的流量入口，而不是像 nodePort 那样给集群打多个孔。 所以，总的来说要使用 Ingress，得先部署 Ingress Controller 实体（相当于前端 Nginx），然后再创建 Ingress （相当于 Nginx 配置的 k8s