Kubernetes之三 k8s中的pod

在k8s中，Pod是一个容器集合，相当于一组docker，同一pod内所有容器使用IPC相互通信,因为它们共享了IPC,UTS,Network。

下面这张图详述了各个容器间的关系

一 Pod中的各个对象：

kind: 定义资源类型, 例如 deployment,service 等

apiVersion: 定义调用的 API 版本, 所支持的版本可以通过 kubectl  API-resources 查看

metadata: 资源提供源数据信息, 如名称, 隶属的名称空间和标签等

spec: 用于定义用户期望的状态, 不同的资源类型

Status: 记录活动对象的当前状态信息, 由 k8s 系统自行维护, 对用户来说为只读字段

二 如何创建pod

kubectl create：

（1）kubectl create命令，是先删除所有现有的东西，重新根据yaml文件生成新的。所以要求yaml文件中的配置必须是完整的

（2）kubectl create命令，用同一个yaml 文件执行替换replace命令，将会不成功，fail掉。

kubectl apply：

  kubectl apply命令，根据配置文件里面列出来的内容，升级现有的。所以yaml文件的内容可以只写需要升级的属性

# 相关资源的命令查询:

kubectl explain pods(spectolerations)

# 导出 pod 对应的 YAML 模版:

kubectl  get pod web YAML --export> webYAML

三镜像拉取方式imagePullPolicy

k8s的配置文件中经常看到有imagePullPolicy属性，这个属性是描述镜像的拉取策略

Always 总是拉取镜像

IfNotPresent 本地有则使用本地镜像,不拉取

Never 只使用本地镜像，从不拉取，即使本地没有

如果省略imagePullPolicy 镜像tag为 :latest 策略为always ，否则 策略为 IfNotPresent

四 pod中的网络代理方式

Service方式: 申明 NodePort 类型, 可以通过任意节点访问,可以实现负载均衡功能

hostPort方式: hostPort是直接将容器的端口与所调度的节点上的端口路由，这样用户就可以通过宿主机的IP加上来访问Pod了

hostNetwork方式: 共享宿主机的网络名称空间

五 创建pod

以下面的yaml创建pod,命令为kubectl create -f firstpodyaml ,在创建之前，需要pull镜像busybox

apiVersion: v1

kind: Pod

metadata:

  name: first-pod

spec:

  containers:

  - name: bash-container

    image: dockerio/busybox

kubectl explain podsstatus 可查看pod的resource

pod 是 kubernetes 中最小的编排单位，通常由一个容器组成 (有时候会有多个容器组成)

nginx-podyaml

将配置apply到k8s

kubectl apply -f nginxyaml

校验部署状态，此时 STATUS 为 Running 表明部署成功

获取 Pod 部署的状态，特别是 IP ,  -o wide 列出IP/Node等更多信息 

kubectl get pods nginx -o wide

获取更加详细的信息

kubectl describe pod nginx

使用 kubectl exec 进入 Pod 的内部容器。如果 Pod 中有多个容器，使用 kubectl exec -c 指定容器

kubectl exec -it nginx sh

在 Pod 容器中执行命令，校验其中的 socket 情况以及 nginx 服务

netstat -tan

wget -q -O - localhost

二、Deployment

在 k8s 中编排应用可以更好地做d性扩容，负载均衡。既然要均衡，一个 Pod 肯定不能均衡，自然要部署多个 Pod

docker-compose 可以简单地通过 docker-compose scale 来扩容，现在用k8s扩容

在k8s中管理 Pod 的称作 Controller，我们可以使用 Deployment 这种 Controller 来为 Pod 进行扩容，当然它还可以滚动升级，回滚，金丝雀等等关于部署的事情

我们编写一个 Deployment 的资源配置文件

我们使用 kubectl apply 部署生效后查看 Pod 以及 Deployment 状态

kubectl get pods -o wide -l 'app=nginx'

三、 Service 

Service 做服务发现 指定 Deployment 或者特定集合 Pod 的网络层抽象

创建NodePort service时，用户可以指定范围为30000-32767的端口，对该端口的访问就能通过 kube-proxy 代理到service后端的pod中

我们使用 kubectl apply 部署生效后查看 Service 状态

kubectl get svc nginx-service -o wide

curl >

此页展示了如何给运行在Kubernetes Pod中的容器定义命令行和参数。

必须有一个Kubernets集群，和一个能和集群沟通的kubectl命令行工具。如果你还没有集群，你可以用 Minikube 建立一个集群。

创建Pod的时候，可以为运行在里面的容器定义一个命令行和参数。定义一个命令行，在配置文件中包含command字段。给这个命令行定义参数包含一个args字段在配置文件中。当Pod创建之后该命令行和参数是不可以修改的。

如果在配置文件中定义了命令行和参数，将覆盖容器镜像提供的默认参数。如果定义了参数但是没有定义命令行，那么参数将和默认的命令行一起使用。更多详细信息可以参考 Commands and Capabilities 。

在本次练习中，创建一个运行一个容器的Pod。下面Pod的配置文件定义了一个命令行和两个参数。

1创建Pod基于YAML配置文件：

2获取运行中的Pod列表：

输出显示在command-demo Pod中运行的容器已完成。

3查看命令行在容器里面的输出，可以查看Pod的日志：

输出展示了HOSTNAME，KUBERNETES_ROOT的环境变量的值：

在前面的例子中，直接通过字符串定义了命令行参数。作为直接用字符串替代方法，你可以用环境变量定义参数：

这意味着你可以使用可用于定义环境变量的任何技术来定义Pod的参数，包括 ConfigMaps 和 Secrets 。

注意：环境变量呈现在括号中，"$(VAR)"。这是在command或args字段中扩展变量所必须的。

在一些情况，你需要在shell中运行你的命令。例如：你的命令可能是由多个命令组合在一起，或者是一个shell脚本。要在shell中运行你的命令，可以这样包装它：

●    Pending：表示pod已经被同意创建，正在等待kube-scheduler选择合适的节点创建，一般是在准备镜像；

●    Running：表示pod中所有的容器已经被创建，并且至少有一个容器正在运行或者是正在启动或者是正在重启；

●    Succeeded：表示所有容器已经成功终止，并且不会再启动；

●    Failed：表示pod中所有容器都是非0(不正常)状态退出；

●    Unknown：表示无法读取pod状态，通常是kube-controller-manager无法与pod通信。

大背景就先不记了（CloudNative、康威定律这些了解一下就好了），先写之前已经学习理解的内容

那就在之前的笔记上面做补充吧

Static pod ： 在Node上手动创建的（未通过Master的api server创建的pod），也未存储于etcd当中

endpoint ： pod的ip+容器暴露的端口

pause容器 ：每一个POD里面都会有一个Pause容器（Pod内所有容器共享Pause容器的ip以及Volume），方便实现容器之间的网络通信以及卷共享，同时Pause容器一般比业务容器要稳定可靠，可以作为Pod的状态标识向Kube-master反映整个Pod的状态

资源： K8s当中管理的对象都叫做K8s的资源，从pod、RC、Server、Node到Cluster（相应的在Yaml或者Json的配置文件当中，根据资源的类型来创建不同的对象）

Replicate描述 ：相当于期望Pod的一个运行状态，在其中会定义好Pod的副本数量，Pod使用的容器（容器repository、端口、容器的限额），Pod的label（replicate controller和Service controller后续都会通过label-select来定位到具体的pod进行管理）

也就是说 Service是通过label来关联它的所有POD的

三种IP地址 ： Node IP、Cluster IP、Pod IP，其中Node IP即为宿主机的IP地址，就是实际的物理ip地址，Cluster IP为K8s内部为每一个Service分配的唯一虚拟IP地址，Cluster IP无法用来与外部进行网络交互，只能在K8s内部使用；Pod IP为Docker0网桥网段里拿到的ip； 需要注意的是这三种IP在互相交互的时候使用的不是通常的路由规则，而是由K8s内部自定义的规则来进行网络通信的

service关联Pod ：在通常情况下，Service当中定义的属性是通过Linux环境变量的方式"注入"到Pod当中的（在容器创建的时候自动引入这些环境变量，主要是Service地址），这些变量已ServiceName_变量属性的方式进行命名；在最新的k8s版本当中，已经引入了DNS来根据Service的名称做Service地址获取（Service域名发现）

NameSpace ：在K8s集群当中也有Namespace的概念，其实就是为了方便多租户共同使用同一套K8s集群所设定的规则，所以在创建任何资源的时候都可以带上--namespace标签来定义对应的租户，如果不带标签的话，或将这些资源挂到default namespace下面

APIServer ： 本质上是一个Restful Server（对外提供k8s当中的各类资源的各种API），同时将这些资源的信息存储于Master上面的etcd当中；

Controller Manager、Scheduler都是通过访问这些API来知晓当前Node上面的资源的状态的，同时采取相应的管理动作，指的一提的是，apiserver本身也是k8s当中的一个Service，其他进程访问Apiserver相当于访问一个Service

Controller Manager ：包含了各种资源、状态的Controller， Replication Controller、Node Controller、ResourceQuota Controller、Namespace、Service Account、Token、Service、Endpoint Controller

Schedule Controller ： 接收由Replicate Controller创建的Pod，将其安置到合适的Node，交给后面Node上面的Kubelet来创建实际的POD；

Schedule Controller会按照一定的规则来针对当前集群中的所有Node进行打分（资源消耗最小原则、资源消耗均衡原则、标签优先原则），然后根据打分以及POD定义当中的一些属性来选择出合适的Node

kubelet ： Node上面的kubelet有几种方式获取Pod清单：

容器健康管理 ： kubelet定期会调用容器的Liveness探针来确定容器的健康状况，liveness探针包括三种方式：

kube-proxy : kube-porxy作为Service的反向代理与负载均衡器，Service外部以Service的Cluster-ip+port或者node ip+Nodeport的方式访问Service业务的时候，这些访问请求会首先被重定向到kube-porxy，然后经过kube-porxy的路由再到达最终的POD

kube-porxy是通过添加iptables来实现重定向的，具体实现是首先kube-porxy会获取一个随机端口作为自己的重定向监听端口，然后添加从外部容器、主机通过Cluster-ip访问的iptables，以及本地的容器、主机通过Nodeport访问的iptables（对于本地容器，重定向目的为kube-porxy的端口，对于外部对象，目的为proxy的ip+proxy的port）

kube-porxy中使用的负载均衡规则为Round Robin算法，除了通常的负载均衡功能之外，还可以配置会话保持（未超时的session一直重定向到同一个Pod），以及配置亲和性（比如按Client ip配置亲和性，让同一个Client ip过来的请求一直访问同一个Pod）

安全管理 ：安全管理分几个阶段，首先是认证，再是授权，最后是准入控制；认证阶段有三种方式进行认证，分别是SSL认证（就是>

以上就是关于Kubernetes之三 k8s中的pod全部的内容，包括:Kubernetes之三 k8s中的pod、k8s部署nginx（Pod、Deployment、Service）、Kubernetes 配置Pod和容器(二)定义容器命令行和参数等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！