kubernetes到底有多难？
看下面的白话： service 网络通信原理
service 由k8s外面的服务作为访问端 内部里面其实是pod
——————————————————————————————————————————————————————
那么说说pod： pod运行在node里面 pod的基础下有k8s的基础功能镜像支持，
pod这个容器共享这Pause容器的网络栈和volume挂载卷（其实是挂起功能和docker的逻辑卷）
_______________________________________________________________________________
那么service 和pod之间有何关联：
k8s给每个pod打上了一个标签（label)[懂docker的都知道]，在此条件之上，比如咱们要找mysql容器
那么他的选择条件就是name=mysql的pod，而这个pod现在被打了mysql的标签，自然serivce就找到了pod的容器
这样就解决了service和pod的关联问题
———————————————————————————————————————————————————————
那么问题来了 当你运行一段时间之后发现需要扩展k8s容器的pod，那么有个概念就叫做 kubernetes RC
还是yaml ，为需要扩容的service关联的pod创建一个Replication Controller 就可以解决 扩容升级问题
写法：
(1) 目标Pod的定义 #就是就是name
(2) 目标Pod需要运行的副本数量(Replicas) #看到yaml的数字吗 就是那里
(3) 要监控的目标Pod的标签(Label) #就是你需要扩容servie关联的pod的标签
————————————————————————————————————————————————————————
注意：Kubernetes的master如果宕掉 整个kubernetes集群就都会宕掉
那么master为什么会宕机呢 答案是他所拥有的功能
功能揭秘：
kube-apiserver ：提供了http Rest接口的关键服务进程 是kubernetes里所有资源的增删改查等操作的唯一入口，是集群控制的入口进程
kube-controller-manager：kubernetes里所有的资源对象的自动化控制中心
kube-scheduler：负责资源调度（Pod调度）的进程 #需要实现的cpu和gpu调度就是在需要在这里实现的
etcd：kubernetes的所有资源对象的数据全都是保存在etcd中
————————————————————————————————————————————————————————
如果你前面不懂node是什么：
揭秘:集群当中除了Master,其他机器都是node节点，每个node都是被master分配负载docker容器，当某个node宕机，其上的工作负载会被master
自动转移到其他节点上去。
哎哟：node上竟然也有命令 不过不要着急 就三个：
kubelet：负责pod对应容器的创建、停止。同时和master节点合作，实现集群管理的基本功能
kube-proxy：实现kubernetes service的通信与负载机制的重要组件
Docker Engine: Docker 引擎，负责本机的容器创建和管理工作 （docker熟练者就很简单了）
—————————————————————————————————————————————————————————
总结一下：
在集群管理方面，Kubernets将集群中的机器划分为一个Master节点和一群工作节点(Node),
其中，在Master节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，
这些进程实现了整个集群的资源管理、Pod调度、弹性收缩、安全控制、系统监控和纠错等管理功能，并且都是全自动完成的。
Node作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。
Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡。
——
txter：Mr.gao
date: 2019.12.12/20:34 星期五
天气：微风
————————————————————————————————————————————————————————————————————————————————————
专门白话介绍一下pod：
pod有什么功能我们知道 ，但是pod具体起了什么作用：
原来pod都包含一个pause容器比如：gcr.io/google_containers/pause-amd64,除此之外还包含多个紧密相关的用户业务容器（user container1;user container2...)这就是pod里面包含的所有容器了
那么pod为什么要设计成这个样子呢：
1.Pause容器被设计成pod的根容器（感觉还和linux的理念很契合，原来不过是把linxu的文件概念变成了以镜像为基础。）那么它代表整个容器组的状态
2.pod里的别个多个容器会共享Pause容器的ip，共享Pause容器挂接的Volume。
总结：那么很显而易见了 这说清楚了pod的构造 以及pause容器为什么存在 和他的用户容器为何把pause作为根容器的意思
那么思考一下：
文章是说：
Kubernetes为每个pod分配唯一的ip地址，一个pod里的多个容器共享ip ：
（注意：是pod里面的多个容器，代表pod1的容器应用pod的共享ip，来和pod2的应用pod的共享ip可以通信）
采用虚拟二层网络技术进行pod间的通信
PS：pod与pod之间当然要通信，不然怎么实现各种功能
——————————————————————————————————————————————————————————————————————————————————————
etcd的存储：
普通的pod:
普通pod一旦被创建，就会被放到etcd中存储，随后被kubernetes master调度到某个具体的node上并进行绑定(Binding),随后pod所对应的node上的kubelet进程实例化
成一组相关的docker容器运行。 当pod里的某个容器停止时，kubernetes会自动监测到这个问题并且重新启动这个pod（重启pod里的所有容器），如果pod所在的node宕机
则会将这个node所有的pod从新调度到其他节点上
总结:其实这也是间接的说明了kubernetes编排工具的功能
静态pod(STatic Pod):
静态pod是由kubelet进行管理的仅存在于特定的node上的pod,他们不能通过API server进行管理,无法与ReplicationController(RC),Deployment.或者DaemonSet进行关联
并且kubelet也无法对他们进行健康检查,静态pod总是由kubelet进行创建的,并且总是在kubelet所在的node进行的 (这可tm绕嘴,还好我坚持看下来了,作者也是为了讲清楚)
简单的说:就是kubelet在node上创建了一个静态pod 这个静态pod只能由node上的kubelet自己进行管理
________________________________________________________________________________________________________________________________\
创建静态Pod有两种方式：配置文件方式和HTTP方式
1.配置文件方式
首先，需要设置kubelet的启动参数"config"，指定kubelet需要监控的配置文件所在的目录，kubelet会定期扫描该目录，并根据该目录中的*.yaml或*.json文件进行创建操作
解释: 其实就是kubelet 启动的时候 指定config=xxx yaml xxx.json 我感觉是这样
但是文章里的static-web.yaml 没一点卵用 没写centos的测试 先在这里搁浅一下,主要先知道这个再说
___________________________________________________________________________________________________________________________________-\
Endpoint
Pod的IP加上这里的容器端口(container Port)，就组成了一个全新的概念---Endpoint 它代表着此Pod里的一个服务进程的对外通讯地址。
一个Pod也存在着多个Endpoint的情况，比如我们把Tomcat定义为一个Pod时，可以对外暴露端口与服务端口这两个Endpoint
简单的说:就是yaml文件里写了这个字段 用来写服务端口和暴露端口 这个和docker容器一模一样的理念
___________________________________________________________________________________________________________________________________\
Event
Event是一个事件的记录,记录里有最早生成时间,最后重现时间,重复次数,...等等.以及导致此事件的原因等众多信息,Event 会关联到某个具体的资源上,是排查故障的重要参考,
Node描述信息包含了Event,而pod同样有Event记录.
当发现pod迟迟无法创建的时候,可以用kubectl describe pod [pod名称] 来查看,定位问题
简单的说:这个Event很重要了 一般服务就是 搭建 使用 拍错 这里就是拍错的重要东西。
什么？不会找pod名称 命令是这个： kubectl get pods ##打印全部运行的容器 找到你需要的pod名称，比如喜欢的dashborad仪表板
————————————————————————————————————————————————————————————————————————————————————————————、
做到这里就需要搭建起来kubernetes了 所以下一篇 开始搭建 将我之前的实验的kubernetes 弄掉 重新搭建一篇 发一篇k8s搭建集群的博客
————————————————————————————————————————————————————————————————————————————————————————————。
txter:Mr.gao
date:2019/12/14|16:34 星期六
天气：微风