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 serice Rc