云原生（十二）Kubernetes篇之Kubernetes基

　　Kubernetes基础入门一、基础知识
　　以上展示了一个master（主节点）和6个worker（工作节点）的k8s集群dockerrunnamehellopodalpine是跑一个容器，容器的粒度有点小kubectlrunhellopodimagealpine跑一个Pod。Pod里面其实也是容器kubectlgetpod以前的dockerpsa所有kubectl在master节点运行，把命令请求发给apiserver。apiserver一系列处理master只负责调度，而workernode才是真正部署应用的。
　　docker是每一个worker节点的运行时环境
　　kubelet负责控制所有容器的启动停止，保证节点工作正常，已经帮助节点交互master
　　master节点的关键组件：kubelet（监工）：所有节点必备的，控制这个节点所有pod的生命周期以及与apiserver交互等工作kubeapiserver：负责接收所有请求，集群内对集群的任何修改都是通过命令行、ui把请求发给apiserver才能执行的。apiserver是整个集群操作对内、对外的唯一入口。不包含我们后来部署应用暴露端口的方式kubeproxy：整个节点的网络流量负责cri：都有容器运行时环境
　　worker节点：kubelet（监工）：所有节点必备的，控制这个节点所有pod的生命周期以及与apiserver交互等工作kubeproxy：整个节点的网络流量负责cri：都有容器运行时环境二、部署一个应用
　　创建一次部署工作（自愈机制）kubectlcreatedeployxxxxxx：命令行会给apiserver发送要部署xxx的请求apiserver把这个请求保存到etcd
　　kubectlcreate帮我们创建k8s集群中的一些对象kubectlcreatehelpkubectlcreatedeployment这次部署的名字image应用的镜像Createadeploymentnamedmynginxthatrunsthenginximagekubectlcreatedeploymentmynginximagenginx最终在一个机器上有pod、这个pod其实本质里面就是一个容器k8snginxmynginx6b74b79f57snlr4defaultdbeac79e1ce942c9bc59c8ca0412674b0k8s镜像（nginx）pod名（mynginx6b74b79f57snlr4）容器名（defaultdbeac79e1ce942c9bc59c8ca0412674b0）CreateadeploymentwithcommandkubectlcreatedeploymentmynginximagenginxdateCreateadeploymentnamedmynginxthatrunsthenginximagewith3replicas。kubectlcreatedeploymentmynginximagenginxreplicas3Createadeploymentnamedmynginxthatrunsthenginximageandexposeport80。kubectlcreatedeploymentmynginximagenginxport80
　　Deployment（部署）在k8s中，通过发布Deployment，可以创建应用程序（dockerimage）的实例（dockercontainer），这个实例会被包含在称为Pod的概念中，Pod是k8s中最小可管理单元。在k8s集群中发布Deployment后，Deployment将指示k8s如何创建和更新应用程序的实例，master节点将应用程序实例调度到集群中的具体的节点上。创建应用程序实例后，KubernetesDeploymentController会持续监控这些实例。如果运行实例的worker节点关机或被删除，则KubernetesDeploymentController将在群集中资源最优的另一个worker节点上重新创建一个新的实例。这提供了一种自我修复机制来解决机器故障或维护问题。在容器编排之前的时代，各种安装脚本通常用于启动应用程序，但是不能够使应用程序从机器故障中恢复。通过创建应用程序实例并确保它们在集群节点中的运行实例个数，KubernetesDeployment提供了一种完全不同的方式来管理应用程序。Deployment处于master节点上，通过发布Deployment，master节点会选择合适的worker节点创建Container（即图中的正方体），Container会被包含在Pod（即蓝色圆圈）里。
　　自愈：针对使用Deployment等部署的应用。
　　kubectlrun：直接启动一个不会产生一次部署信息。所以删除就没
　　kubectlcreatedeploy：启动一个Pod，以及记录这次部署信息。所以，这个pod即使挂了，这次部署信息有，就会强制同步到这次部署信息期望的最终结果；kubectlgetdeploy，pod都有内容三、应用程序探索了解KubernetesPods（容器组）了解KubernetesNodes（节点）排查故障
　　创建Deployment后，k8s创建了一个Pod（容器组）来放置应用程序实例（container容器）。
　　1、了解Pod
　　Pod（容器组）是一个k8s中一个抽象的概念，用于存放一组container（可包含一个或多个container容器，即图上正方体），以及这些container（容器）的一些共享资源。这些资源包括：共享存储，称为卷（Volumes），即图上紫色圆柱网络，每个Pod（容器组）在集群中有个唯一的IP，pod（容器组）中的container（容器）共享该IP地址container（容器）的基本信息，例如容器的镜像版本，对外暴露的端口等
　　Pod（容器组）是k8s集群上的最基本的单元。当我们在k8s上创建Deployment时，会在集群上创建包含容器的Pod（而不是直接创建容器）。每个Pod都与运行它的worker节点（Node）绑定，并保持在那里直到终止或被删除。如果节点（Node）发生故障，则会在群集中的其他可用节点（Node）上运行相同的Pod（从同样的镜像创建Container，使用同样的配置，IP地址不同，Pod名字不同）。
　　TIP重要：Pod是一组容器（可包含一个或多个应用程序容器），以及共享存储（卷Volumes）、IP地址和有关如何运行容器的信息。如果多个容器紧密耦合并且需要共享磁盘等资源，则他们应该被部署在同一个Pod（容器组）中。2、了解Node
　　Pod（容器组）总是在Node（节点）上运行。Node（节点）是kubernetes集群中的计算机，可以是虚拟机或物理机。每个Node（节点）都由master管理。一个Node（节点）可以有多个Pod（容器组），kubernetesmaster会根据每个Node（节点）上可用资源的情况，自动调度Pod（容器组）到最佳的Node（节点）上。
　　每个KubernetesNode（节点）至少运行：Kubelet，负责master节点和worker节点之间通信的进程；管理Pod（容器组）和Pod（容器组）内运行的Container（容器）。kubeproxy，负责进行流量转发容器运行环境（如Docker）负责下载镜像、创建和运行容器等。
　　Kubelet启动的Pod每个都有Ip，全集群任意位置均可访问kubeadminitapiserveradvertiseaddress10。170。11。8imagerepositoryregistry。cnhangzhou。aliyuncs。comlansonk8simageskubernetesversionv1。21。0servicecidr10。96。0。016podnetworkcidr192。168。0。016podnetworkcidr192。168。0。016：pod的ip范围
　　calico：网络组件：【扁平化网络】3、故障排除
　　kubectlget显示资源列表kubectlget资源类型获取类型为Deployment的资源列表kubectlgetdeployments获取类型为Pod的资源列表kubectlgetpods获取类型为Node的资源列表kubectlgetnodes
　　查看所有名称空间的DeploymentkubectlgetdeploymentsAkubectlgetdeploymentsallnamespaces查看kubesystem名称空间的Deploymentkubectlgetdeploymentsnkubesystem
　　并不是所有的对象都在名称空间中在名称空间里kubectlapiresourcesnamespacedtrue不在名称空间里kubectlapiresourcesnamespacedfalse
　　kubectldescribe显示有关资源的详细信息kubectldescribe资源类型资源名称查看名称为nginxXXXXXX的Pod的信息kubectldescribepodnginxXXXXXX查看名称为nginx的Deployment的信息kubectldescribedeploymentmynginx
　　kubectllogs查看pod中的容器的打印日志（和命令dockerlogs类似）kubectllogsPod名称查看名称为nginxpodXXXXXXX的Pod内的容器打印的ahrefhttps：www。bs178。comrizhitargetblankclassinfotextkey日志a本案例中的nginxpod没有输出ahrefhttps：www。bs178。comrizhitargetblankclassinfotextkey日志a，所以您看到的结果是空的kubectllogsfnginxpodXXXXXXX
　　kubectlexec在pod中的容器环境内执行命令（和命令dockerexec类似）kubectlexecPod名称操作命令在名称为nginxpodxxxxxx的Pod中运行bashkubectlexecitnginxpodxxxxxxbinbash注意：新版1。21。0提示这个命令会过期
　　4、kubectlrun
　　也可以独立跑一个Podkubectlrunhelpkubectlrunnginximagenginx
　　总结：kubectlcreate资源创建任意资源kubectlcreatedeploy创建部署kubectlrun只创建一个Podkubectlget资源名（nodepoddeploy）nxxx（指定名称空间，默认是default）获取资源kubectldescribe资源名（nodepoddeploy）xxx描述某个资源的详细信息kubectllogs资源名查看ahrefhttps：www。bs178。comrizhitargetblankclassinfotextkey日志akubectlexecitpod名命令进pod并执行命令kubectldelete资源名（nodepoddeploy）xxx删除资源
　　四、应用外部可见了解Kubernetes中的Service了解标签（Label）和标签选择器（LabelSelector）对象如何与Service关联在Kubernetes集群外用Service暴露应用1、KubernetesService总览KubernetesPod是转瞬即逝的。Pod实际上拥有生命周期。当一个工作Node挂掉后，在Node上运行的Pod也会消亡。ReplicaSet会自动地通过创建新的Pod驱动集群回到目标状态，以保证应用程序正常运行。Kubernetes的Service是一个抽象层，它定义了一组Pod的逻辑集，并为这些Pod支持外部流量暴露、负载平衡和服务发现。Service使从属Pod之间的松耦合成为可能。和其他Kubernetes对象一样，Service用YAML或者JSON来定义。Service下的一组Pod通常由LabelSelector（请参阅下面的说明为什么您可能想要一个spec中不包含selector的服务）来标记。尽管每个Pod都有一个唯一的IP地址，但是如果没有Service，这些IP不会暴露在群集外部。Service允许您的应用程序接收流量。Service也可以用在ServiceSpec标记type的方式暴露ClusterIP（默认）在集群的内部IP上公开Service。这种类型使得Service只能从集群内访问。NodePort使用NAT在集群中每个选定Node的相同端口上公开Service。使用：从集群外部访问Service。是ClusterIP的超集。LoadBalancer在当前云中创建一个外部负载均衡器（如果支持的话），并为Service分配一个固定的外部IP。是NodePort的超集。ExternalName通过返回带有该名称的CNAME记录，使用任意名称（由spec中的externalName指定）公开Service。不使用代理。这种类型需要kubedns的v1。7或更高版本。2、Service和Label
　　Service通过一组Pod路由通信。Service是一种抽象，它允许Pod死亡并在Kubernetes中复制，而不会影响应用程序。在依赖的Pod（如应用程序中的前端和后端组件）之间进行发现和路由是由KubernetesService处理的。
　　Service匹配一组Pod是使用标签（Label）和选择器（Selector），它们是允许对Kubernetes中的对象进行逻辑操作的一种分组原语。标签（Label）是附加在对象上的键值对，可以以多种方式使用：指定用于开发，测试和生产的对象嵌入版本标签使用Label将对象进行分类
　　3、kubectlexposekubectlexposedeploymenttomcat6port8912targetport8080typeNodePortport：集群内访问service的端口8912targetport：pod容器的端口8080nodePort：每个机器开发的端口30403进行验证kubectlgetsvccurlip：portkubectlexpose暴露，成一个负载均衡网络kubectlexec进去pod修改，并测试负载均衡
　　五、伸缩应用程序扩缩容用kubectl扩缩应用程序扩缩一个Deployment
　　我们创建了一个Deployment，然后通过服务提供访问Pod的方式。我们发布的Deployment只创建了一个Pod来运行我们的应用程序。当流量增加时，我们需要对应用程序进行伸缩操作以满足系统性能需求。
　　扩容的Pod会自动加入到他之前存在的Service（负载均衡网络）kubectlscalereplicas3deploymenttomcat6持续观测效果watchkubectlgetpodsowide
　　六、执行滚动升级使用kubectl执行滚动更新
　　滚动更新允许通过使用新的实例逐步更新Pod实例从而实现Deployments更新，停机时间为零。
　　与应用程序扩展类似，如果暴露了Deployment，服务（Service）将在更新期间仅对可用的pod进行负载均衡。可用Pod是应用程序用户可用的实例。
　　滚动更新允许以下操作：将应用程序从一个环境提升到另一个环境（通过容器镜像更新）回滚到以前的版本持续集成和持续交付应用程序，无需停机
　　应用升级：tomcat：alpine、tomcat：jre8alpinekubectlsetimagedeploymentmynginx2nginxnginx：1。9。1联合jenkins形成持续集成，灰度发布功能kubectlsetimagedeployment。appstomcat6tomcattomcat：jre8alpine可以携带record参数，记录变更回滚升级查看历史记录kubectlrollouthistorydeployment。appstomcat6kubectlrollouthistorydeploytomcat6回滚到指定版本kubectlrolloutundodeployment。appstomcat6torevision1kubectlrolloutundodeploytomcat6torevision1
　　七、使用配置文件方式1、部署一个应用apiVersion：appsv1与k8s集群版本有关，使用kubectlapiversions即可查看当前集群支持的版本kind：Deployment该配置的类型，我们使用的是Deploymentmetadata：译名为元数据，即Deployment的一些基本属性和信息name：nginxdeploymentDeployment的名称labels：标签，可以灵活定位一个或多个资源，其中key和value均可自定义，可以定义多组，目前不需要理解app：nginx为该Deployment设置key为app，value为nginx的标签spec：这是关于该Deployment的描述，可以理解为你期待该Deployment在k8s中如何使用replicas：1使用该Deployment创建一个应用程序实例selector：标签选择器，与上面的标签共同作用，目前不需要理解matchLabels：选择包含标签app：nginx的资源app：nginxtemplate：这是选择或创建的Pod的模板metadata：Pod的元数据labels：Pod的标签，上面的selector即选择包含标签app：nginx的Podapp：nginxspec：期望Pod实现的功能（即在pod中部署）containers：生成container，与docker中的container是同一种name：nginxcontainer的名称image：nginx：1。7。9使用镜像nginx：1。7。9创建container，该container默认80端口可访问
　　kubectlapplyfxxx。yaml
　　2、暴露应用apiVersion：v1kind：Servicemetadata：name：nginxserviceService的名称labels：Service自己的标签app：nginx为该Service设置key为app，value为nginx的标签spec：这是关于该Service的定义，描述了Service如何选择Pod，如何被访问selector：标签选择器app：nginx选择包含标签app：nginx的Podports：name：nginxport端口的名字protocol：TCP协议类型TCPUDPport：80集群内的其他容器组可通过80端口访问ServicenodePort：32600通过任意节点的32600端口访问ServicetargetPort：80将请求转发到匹配Pod的80端口type：NodePortSerive的类型，ClusterIPNodePortLoaderBalancer
　　3、扩缩容
　　修改deployment。yaml中的replicas属性即可
　　完成后运行kubectlapplyfxxx。yaml
　　4、滚动升级
　　修改deployment。yaml中的imageName属性等
　　完成后运行kubectlapplyfxxx。yaml
　　以上都可以直接kubectleditdeployservice等，修改完成后自动生效