Kubernetes从云原生到kubernetes

　　一、前言二、kubernetes和云原生
　　CloudNative直接翻译为云原生，云原生官网：https：www。cncf。io
　　CNCF，表示CloudNativeComputingFoudation，翻译为云原生计算基金会，属于Linux基金会，初衷是围绕云原生服务云计算，维护和集成开源技术，支持编排容器化微服务架构应用。
　　时至今日，Kubernetes逐渐已经成为云原生失败的基础设置。
　　Docker是容器化技术，Kubernetes是一种容器编排技术，之前还有一个DockerSwarm也是一种容器编排技术，但是已经不被使用。
　　云原生这三字，云表示在云服务器上部署，原生的意义就是部署在一个陌生的环境，像部署在自己熟悉的环境上，类似于JVM一次编译，到处运行。
　　要实现云原生这个一次编译，到处运行，涉及很多组件，从小到大，Docker是容器化部署，Kubernetes是容器编排工具（DockerSwarm也是），对Docker进行编排，就是通过yaml文件来实现；Helm是包管理工具，对Kubernetes的yaml进行编排，Helm中通过if块可以用values。yaml文件中变量精确的决定kubernetesyaml文件中哪一行是否需要被运用。
　　kubernetes是云原生时代基础设施，如下图：
　　上图表示，将应用部署在Kubernetes集群上，这样应用就可以在公有云私有云混合云上无缝迁移。应用包括用于数据存储的有状态的应用，使用StatefulSet部署，不用于数据存储的无状态的应用，使用Deployment部署。
　　Kubernetes四种部署方式：DeploymentStatefulSetDaemonSetJob（CronJob）
　　ReplicaSet存在的意义就是replicas这个属性howmanyPods
　　Deployment存在的意义就是无状态
　　StatefulSet存在的意义就是有状态
　　DaemonSet存在的意义就是日志监控
　　Job（CronJob）存在的意义是一次性任务和定时任务
　　小结：云原生这三字，云表示在云服务器上部署，原生的意义就是部署在一个陌生的环境，像部署在自己熟悉的环境上，类似于JVM一次编译，到处运行。容器化部署实现了这个目标，Kubernetes是一种容器编排技术，所以说Kubernetes是云原生时代基础设施，这就是Docker、Kubernetes与云原生的关系。三、从DockerSwarm到Kubernetes
　　kubernetes本质是一个容器编排技术，docker内置的dockerswarm也是做容器编排的，都是管理和编排DockerContainer容器，但是对于容器编排，k8s更加优秀，是现在的主流。
　　重点学习kubernetes，dockerswarmy了解即可，知道有这个东西即可。
　　Github上：https：github。comkuberneteskubernetes
　　dockerswarm架构设计（了解即可）
　　四、kubernetes组件和架构简介4。1kubernetes组件
　　本节官方地址（K8SDocsConcepts）：https：kubernetes。iodocsconcepts4。1。1Container
　　（1）先以container为起点，k8s既然是容器编排工具，那么一定会有container
　　4。1。2Pod
　　那k8s如何操作这些container呢？从感性的角度来讲，得要有点逼格，k8s不想直接操作container，因为操作container的事情是docker来做的，k8s中要有自己的最小操作单位，称之为Pod说白了，Pod就是一个或多个Container的组合
　　官方解释：https：kubernetes。iodocsconceptsworkloadspodspod
　　APod（asinapodofwhalesorpeapod）isagroupofoneormorecontainers（suchasDockercontainers），withsharedstoragenetwork，andaspecificationforhowtorunthecontainers。4。1。3ReplicaSet
　　那Pod的维护谁来做呢？那就是ReplicaSet，通过selector来进行管理
　　官方解释：https：kubernetes。iodocsconceptsworkloadscontrollersreplicaset
　　AReplicaSetisdefinedwithfields，includingaselectorthatspecifieshowtoidentifyPodsitcanacquire，anumberofreplicasindicatinghowmanyPodsitshouldbemaintaining，andapodtemplatespecifyingthedataofnewPodsitshouldcreatetomeetthenumberofreplicascriteria。4。1。4Deployment
　　Pod和ReplicaSet的状态如何维护和监测呢？Deployment
　　官网是如何描述的：https：kubernetes。iodocsconceptsworkloadscontrollersdeployment
　　ADeploymentcontrollerprovidesdeclarativeupdatesforPodsandReplicaSets。YoudescribeadesiredstateinaDeployment，andtheDeploymentcontrollerchangestheactualstatetothedesiredstateatacontrolledrate。YoucandefineDeploymentstocreatenewReplicaSets，ortoremoveexistingDeploymentsandadoptalltheirresourceswithnewDeployments。4。1。5Label与Selector
　　不妨把相同或者有关联的Pod分门别类一下，那怎么分门别类呢？Label
　　官网是如何描述的：https：kubernetes。iodocsconceptsoverviewworkingwithobjectslabels
　　Labelsarekeyvaluepairsthatareattachedtoobjects，suchaspods。
　　label可以在任何类型的资源上，然后用selector选择器来选择，比如pod、node，都可以打标签。4。1。6Service
　　具有相同label的service要是能够有个名称就好了，Service
　　看官网上怎么说：https：kubernetes。iodocsconceptsservicesnetworkingservice
　　AnabstractwaytoexposeanapplicationrunningonasetofPodsasanetworkservice。
　　WithKubernetesyoudon’tneedtomodifyyourapplicationtouseanunfamiliarservicediscoverymechanism。KubernetesgivesPodstheirownIPaddressesandasingleDNSnameforasetofPods，andcanloadbalanceacrossthem。4。1。7Node
　　上述说了这么多，Pod运行在哪里呢？当然是机器咯，比如一台centos机器，我们把这个机器称作为Node。
　　看看官网怎么说：https：kubernetes。iodocsconceptsarchitecturenodes
　　AnodeisaworkermachineinKubernetes，previouslyknownasaminion。AnodemaybeaVMorphysicalmachine，dependingonthecluster。Eachnodecontainstheservicesnecessarytorunpodsandismanagedbythemastercomponents。4。1。8多Node节点组成的集群
　　难道只有一个Node吗？显然不太合适，多台Node共同组成集群才行嘛
　　画个图表示一下咯，最好能把之前的Label，Service也一起画上去，整体感受一下
　　此时，我们把目光转移到由3个Node节点组成的MasterNode集群
　　4。2kubernetes架构
　　这个集群要配合完成一些工作，总要有一些组件的支持吧？接下来我们来想想有哪些组件，然后画一个相对完整的架构图
　　01总得要有一个操作集群的客户端，也就是和集群打交道
　　回答：kubectl，每个集群node上都可以使用kubectl，只要root。kubeconfig文件。
　　02请求肯定是到达MasterNode，然后再分配给WorkerNode创建Pod之类的关键是命令通过kubectl过来之后，是不是要认证授权一下？
　　回答：MasterNode上的apiserver，etckubernetesmanifests目录下有kubeapiserver。yaml文件
　　03请求过来之后，MasterNode中谁来接收？
　　回答：APIServer
　　04API收到请求之后，接下来调用哪个WorkerNode创建Pod，Container之类的，得要有调度策略
　　回答：Master节点的上的静态PodScheduler来负责。
　　官方资料：https：kubernetes。iodocsconceptsschedulingkubescheduler
　　05Scheduler通过不同的策略，真正要分发请求到不同的WorkerNode上创建内容，具体谁负责？
　　回答：ControllerManager
　　06WorkerNode接收到创建请求之后，具体谁来负责？
　　回答：Kubelet服务，最终Kubelet会调用DockerEngine，创建对应的容器〔这边也反应出一点，在Node上需要有DockerEngine，才能创建维护容器〕
　　07会不会涉及到域名解析的问题？
　　回答：主节点上的CoreDNS服务
　　08是否需要有监控面板能够监测整个集群的状态？
　　回答：Dashboard
　　09集群中这些数据如何保存？
　　回答：分布式存储ETCD
　　10至于像容器的持久化存储，网络等可以联系一下
　　回答：Docker中的内容
　　11不妨用一个图片总结整个流程
　　回答：
　　这个图片上告诉我们：
　　（1）对于主节点来说，kubectl连接主节点的所有操作，都必须通过apiserver的认证、授权、准入控制，才能正常进行；
　　（2）四个静态Pod：apiservercontrollerManagerscheduleretcd都是运行在主节点上，apiserver用于认证、打开外网、rbac授权、controllerManager用来管理各种controller，包括replicasetdeploymentstatefulsetdaemonsetjobcronjob，scheduler决定某个Pod分配哪个Node上，etcd作为配置中心存放数据。
　　（3）dashboard提供简单的可视化，完整的可视化还是需要PrometheusGrafana监控
　　（4）默认情况下主节点有污点Taint，不分配Pod运行
　　（5）每个节点上都会有kubelet服务，可以使用systemctlstatuskubelet查看
　　每个节点上都会有docker服务，可以使用systemctlstatusdocker查看，其作用是将镜像image运行起来变为容器Container
　　每个节点上都会有kubeproxy容器，可以使用kubectlgetpodowidenkubesystem查看，其作用是将kubectl发送到service的请求路由到具体的Pod上；
　　每个节点上都会有calicofluend容器，可以使用kubectlgetpodowidenkubesystem查看，其作用Node之间网络通信；
　　集群一些节点上有dns容器，可以使用kubectlgetpodowidenkubesystem查看，其作用使用将serviceName。namespace解析为集群内ip，也可以解析外网域名，通过配置etcresolv。confnameserver域名解析服务器列表和etchosts本地域名解析文件来实现。
　　再来一张横向架构图图，加深理解，如下：
　　五、尾声
　　从云原生到kubernetes，完成了。