Kubernetes | 抓包浅浅的分析一下Pod的创建过程

通过 kubectl 工具创建新的Pod，kubectl 会将pod对象信息（json格式）提交给apiserver。

而apiserver连接etcd则没有进行抓包，之前抓了几次貌似都是tcp包看不出来啥内容，后面有空再研究研究吧。

这几个tcp包是apiserver推给scheduler的事件，主要是告诉scheduler：有新的pod创建了。

scheduler向apiserver提交bingding *** 作，将pod binding到timo节点上，并且是调度成功的，后面的事情那就是kubelet去执行的了。

查看一下集群的节点。

有的朋友很疑惑，为啥NotReady也能调度成功，这是因为我将nodekubernetesio/not-ready污点给干掉了，生产环境肯定不能这样做的。

另外这个并不是完整的集群，controller-manager和kube-proxy以及网络插件都没有，主要目的是想研究一下pod的创建过程的交互细节是怎么样的，集群之间也没有使用证书通信，低版本的kubernetes可以使用8080非加密端口，这样抓包就可以看到内容了。

从上面抓包的内容看出来几个问题。

1、kubectl创建pod是将json格式的对象信息提交给apiserver的。

2、apiserver将pod信息存入etcd后就会生成对应的事件，然后将事件通知给scheduler（从抓包也看出来是apiserver主动通知的，apiserver和scheduler之间使用watch机制）。

3、scheduler监听到事件后，向apiserver提交binding *** 作，将pod binding到指定的node上。

如果朋友们有兴趣，可以安装低版本的Kubernetes来抓包分析看看。

DaemonSet 确保全部Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有Pod。

在每一个node节点上只调度一个Pod，因此无需指定replicas的个数，比如：

1）在每个node上都运行一个日志采集程序，负责收集node节点本身和node节点之上的各个Pod所产生的日志

2）在每个node上都运行一个性能监控程序，采集该node的运行性能数据

可以通过kubectl命令行方式获取更加详细信息

controller/daemonsetdemoyml

DaemonSet有两种更新策略类型：

1）OnDelete：这是向后兼容性的默认更新策略。使用 OnDelete 更新策略，在更新DaemonSet模板后，只有在手动删除旧的DaemonSet pod时才会创建新的DaemonSet pod。这与Kubernetes15或更早版本中DaemonSet的行为相同。

2）RollingUpdate：使用 RollingUpdate 更新策略，在更新DaemonSet模板后，旧的DaemonSet pod将被终止，并且将以受控方式自动创建新的DaemonSet pod。

我们先从整体上看一下Kubernetes的一些理念和基本架构，然后从网络、资源管理、存储、服务发现、负载均衡、高可用、rollingupgrade、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性。当然也会包括一些需要注意的问题。主要目的是帮助大家快速理解Kubernetes的主要功能，今后在研究和使用这个具的时候有所参考和帮助。1Kubernetes的一些理念：用户不需要关心需要多少台机器，只需要关心软件（服务）运行所需的环境。以服务为中心，你需要关心的是api，如何把大服务拆分成小服务，如何使用api去整合它们。保证系统总是按照用户指定的状态去运行。不仅仅提给你供容器服务，同样提供一种软件系统升级的方式；在保持HA的前提下去升级系统是很多用户最想要的功能，也是最难实现的。那些需要担心和不需要担心的事情。更好的支持微服务理念，划分、细分服务之间的边界，比如lablel、pod等概念的引入。对于Kubernetes的架构，可以参考官方文档。大致由一些主要组件构成，包括Master节点上的kube-apiserver、kube-scheduler、kube-controller-manager、控制组件kubectl、状态存储etcd、Slave节点上的kubelet、kube-proxy，以及底层的网络支持（可以用Flannel、OpenVSwitch、Weave等）。看上去也是微服务的架构设计，不过目前还不能很好支持单个服务的横向伸缩，但这个会在Kubernetes的未来版本中解决。2Kubernetes的主要特性会从网络、服务发现、负载均衡、资源管理、高可用、存储、安全、监控等方面向大家简单介绍Kubernetes的这些主要特性->由于时间有限，只能简单一些了。另外，对于服务发现、高可用和监控的一些更详细的介绍，感兴趣的朋友可以通过这篇文章了解。1）网络Kubernetes的网络方式主要解决以下几个问题：a紧耦合的容器之间通信，通过Pod和localhost访问解决。bPod之间通信，建立通信子网，比如隧道、路由，Flannel、OpenvSwitch、Weave。cPod和Service，以及外部系统和Service的通信，引入Service解决。Kubernetes的网络会给每个Pod分配一个IP地址，不需要在Pod之间建立链接，也基本不需要去处理容器和主机之间的端口映射。注意：Pod重建后，IP会被重新分配，所以内网通信不要依赖PodIP；通过Service环境变量或者DNS解决。2）服务发现及负载均衡kube-proxy和DNS，在v1之前，Service含有字段portalip和publicIPs，分别指定了服务的虚拟ip和服务的出口机ip，publicIPs可任意指定成集群中任意包含kube-proxy的节点，可多个。portalIp通过NAT的方式跳转到container的内网地址。在v1版本中，publicIPS被约定废除，标记为deprecatedPublicIPs，仅用作向后兼容，portalIp也改为ClusterIp,而在serviceport定义列表里，增加了nodePort项，即对应node上映射的服务端口。DNS服务以addon的方式，需要安装skydns和kube2dns。kube2dns会通过读取KubernetesAPI获取服务的clusterIP和port信息，同时以watch的方式检查service的变动，及时收集变动信息，并将对于的ip信息提交给etcd存档，而skydns通过etcd内的DNS记录信息，开启53端口对外提供服务。大概的DNS的域名记录是servicenamenamespacetenxdomain,“tenxdomain”是提前设置的主域名。注意：kube-proxy在集群规模较大以后，可能会有访问的性能问题，可以考虑用其他方式替换，比如HAProxy，直接导流到Service的endpints或者Pods上。Kubernetes官方也在修复这个问题。3）资源管理有3个层次的资源限制方式，分别在Container、Pod、Namespace层次。Container层次主要利用容器本身的支持，比如Docker对CPU、内存、磁盘、网络等的支持；Pod方面可以限制系统内创建Pod的资源范围，比如最大或者最小的CPU、memory需求；Namespace层次就是对用户级别的资源限额了，包括CPU、内存，还可以限定Pod、rc、service的数量。资源管理模型－》简单、通用、准确，并可扩展目前的资源分配计算也相对简单，没有什么资源抢占之类的强大功能，通过每个节点上的资源总量、以及已经使用的各种资源加权和，来计算某个Pod优先非配到哪些节点，还没有加入对节点实际可用资源的评估，需要自己的schedulerplugin来支持。其实kubelet已经可以拿到节点的资源，只要进行收集计算即可，相信Kubernetes的后续版本会有支持。4）高可用主要是指Master节点的HA方式官方推荐利用etcd实现master选举，从多个Master中得到一个kube-apiserver保证至少有一个master可用，实现highavailability。对外以loadbalancer的方式提供入口。这种方式可以用作ha，但仍未成熟，据了解，未来会更新升级ha的功能。一张图帮助大家理解：也就是在etcd集群背景下，存在多个kube-apiserver，并用pod-master保证仅是主master可用。同时kube-sheduller和kube-controller-manager也存在多个，而且伴随着kube-apiserver同一时间只能有一套运行。5）rollingupgradeRC在开始的设计就是让rollingupgrade变的更容易，通过一个一个替换Pod来更新service，实现服务中断时间的最小化。基本思路是创建一个复本为1的新的rc，并逐步减少老的rc的复本、增加新的rc的复本，在老的rc数量为0时将其删除。通过kubectl提供，可以指定更新的镜像、替换pod的时间间隔，也可以rollback当前正在执行的upgrade *** 作。同样，Kuberntes也支持多版本同时部署，并通过lable来进行区分，在service不变的情况下，调整支撑服务的Pod，测试、监控新Pod的工作情况。6）存储大家都知道容器本身一般不会对数据进行持久化处理，在Kubernetes中，容器异常退出，kubelet也只是简单的基于原有镜像重启一个新的容器。另外，如果我们在同一个Pod中运行多个容器，经常会需要在这些容器之间进行共享一些数据。Kuberenetes的Volume就是主要来解决上面两个基础问题的。Docker也有Volume的概念，但是相对简单，而且目前的支持很有限，Kubernetes对Volume则有着清晰定义和广泛的支持。其中最核心的理念：Volume只是一个目录，并可以被在同一个Pod中的所有容器访问。而这个目录会是什么样，后端用什么介质和里面的内容则由使用的特定Volume类型决定。创建一个带Volume的Pod：specvolumes指定这个Pod需要的volume信息speccontainersvolumeMounts指定哪些container需要用到这个VolumeKubernetes对Volume的支持非常广泛，有很多贡献者为其添加不同的存储支持，也反映出Kubernetes社区的活跃程度。emptyDir随Pod删除，适用于临时存储、灾难恢复、共享运行时数据，支持RAM-backedfilesystemhostPath类似于Docker的本地Volume用于访问一些本地资源（比如本地Docker）。gcePersistentDiskGCEdisk-只有在GoogleCloudEngine平台上可用。awsElasticBlockStore类似于GCEdisk节点必须是AWSEC2的实例nfs-支持网络文件系统。rbd-RadosBlockDevice-Cephsecret用来通过KubernetesAPI向Pod传递敏感信息，使用tmpfs（aRAM-backedfilesystem）persistentVolumeClaim-从抽象的PV中申请资源，而无需关心存储的提供方glusterfsiscsigitRepo根据自己的需求选择合适的存储类型，反正支持的够多，总用一款适合的:）7）安全一些主要原则：基础设施模块应该通过APIserver交换数据、修改系统状态，而且只有APIserver可以访问后端存储（etcd）。把用户分为不同的角色：Developers/ProjectAdmins/Administrators。允许Developers定义secrets对象，并在pod启动时关联到相关容器。以secret为例，如果kubelet要去pull私有镜像，那么Kubernetes支持以下方式：通过dockerlogin生成dockercfg文件，进行全局授权。通过在每个namespace上创建用户的secret对象，在创建Pod时指定imagePullSecrets属性（也可以统一设置在serviceAcouunt上），进行授权。认证（Authentication）APIserver支持证书、token、和基本信息三种认证方式。授权（Authorization）通过apiserver的安全端口，authorization会应用到所有>

网上找了很多办法都没用，自己琢磨了下，在环境变量里设置fieldRef读取statushostIP的值，这个其实就是宿主机的值，再在Pod里通过环境变量读取就好了。

同理一样可以获得节点名称，所在的命名空间等

这是一个yaml示例

Kubernetes Pods

当你在模块 2 中创建一个Deployment的时候，Kubernetes创建了一个 Pod 来放置你的应用实例。Pod是Kubernetes中的一个抽象概念，一个Pod包含了一组应用容器（比如Docker或者rkt）和这些容器共用的资源。这些资源包括：

Pod模拟出了一个应用运行所需要的"逻辑主机",并且还能包含一些紧密耦合的其他应用。举个例子，在你的Nodejs应用中，一个Pod可能包含了两个容器，除了Nodesjs本身以外还有一个是用来给Nodejs webserver提供数据来开放给外部访问。在Pod中的容器共享同一个IP地址和端口区间，它们总是放置在同一个地方，一起被调度，并且运行在基于同一个Node上的共享上下文之中。

Pod在Kubenetes中是最小不可分割的单元。当我们在Kubenetes上创建一个Deployments的时候，Deployment会创建Pod并且同时在Pod里面创建容器（不要直接创建容器）。每个Pod都会放在预定的Node上面，并且会一直存在于那里直到运行终止（这个要根据restart策略来看具体情况）或者被删除。万一Node宕机了，整个Pod会被调度到集群中另外一个可用的Node上去

一个Pod总是运行在一个 Node 上。在Kubernetes中一个Node是一个执行具体工作的机器，它可用是虚拟机也可用是物理机，这个取决于所在的集群。每个Node都由Master统一管理。每个Node上面可用有多个Pod，Kubernetes Master会自动在Node之间处理调度相关的处理。Master的自动调度会记录每个Node上的可用资源。

每个Kubernetes Node运行至少需要：

假如几个容器互相紧密耦合并且需要使用一些共享的资源（比如磁盘），那它们应该要放到同一个Pod中当做一个整体进行调度

在模块 2 中，我们使用了kubectl命令行工具。在模块3中，我们会继续使用它来获取所部署应用的相关信息和它们所运行的环境信息。下面是kubectl的一些最常用的 *** 作：

kubectl get - 列出所有的资源

kubectl describe - 列出某个资源的详细信息

kubectl logs - 输出pod中容器的日志

kubectl exec - 在pod中的某个容器里面执行命令

你可以使用这些命令来观察应用程序什么时候被部署了，它现在处于什么状态，它运行在何处和它当前的配置是什么

以上就是关于Kubernetes | 抓包浅浅的分析一下Pod的创建过程全部的内容，包括:Kubernetes | 抓包浅浅的分析一下Pod的创建过程、k8s-pod之DaemonSet、请教kubernetes部署问题，pod一直处于pending状态等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！