Kubernetes学习笔记-从应用访问pod原数据以及其他资源（1）20220505

1、通过Downward API传递元数据
之前学过的通过环境变量或configMap和secret卷向应用传递配置数据，这对于pod调度、运动前预设的数据是可行的，但对于那些不能预先知道的数据，如pod的ip、主机名或pod自身的名称（当名称被生成器，如当pod通过ReplicaSet或类似控制器生成时）呢，此外，对于那些已经在别处定义的数据；比如pod的标签或注解呢？不想在多个地方重复保留同样的数据
对此问题，可以通过kubernetes Downward api解决。Downward API允许通过环境变量或文件（在downward api卷）传递pod的元数据。downward api方式与REST endpoint不同，不需要通过访问的方式获取数据，这种方式是将在pod的定义和状态中取得的数据作为环境变量和文件的值
1）可用的元数据
Downward API可以给在pod中运行的进程暴露pod的元数据，目前可以给容器传递以下数据：

• pod的名称
• pod的IP
• pod所在的命名空间
• pod运行节点的名称
• pod运行所归属的服务账号的名称
• 每个容器请求的cpu和内存的使用量
• 每个容器可以使用的cpu和内存的限制
• pod的标签
• pod的注解

如上除了标签和注解外，都既可用通过环境变量也可以通过Downward API卷传递给容器。
2）通过环境变量暴露元数据
pod的yaml文件创建pod，yaml文件中定义了环境变量以及变量的值的来源。
pod的名称、ip和命名空间可以通过pod_NAME、pod_IP和pod_NAMESPACE这几个环境变量分别暴露，容器运行的节点通过NODE_NAME变量暴露。服务账号可以使用环境变量SERVICE_ACCOUNT
通过kubectl exec命令查看容器中所有环境变量：
$kubectl exec downward env
3）通过downwardAPI卷来传递元数据
除了上面讲的环境变量，还可以使用文件方式，定义一个downwardAPI卷挂载到容器中。由于标签和注解不能通过环境变量暴露，所以必须使用downwardAPI卷来暴露pod标签或注解
和环境变量方式一样，在创建pod的yaml文件中定义downwardAPI卷，通过ect/downward目录挂载到我们容器，卷所包含的文件通过卷定义中的downwardAPI.items属性来定义
对于想要在文件中保存的每一个pos级的字段或容器资源字段，都分别在downwardAPI.items中说明了元数据却被保存和引用的path（文件名）
注意：与configMap和secret卷一样，可以通过pod定义中downwardAPI卷的defaultMode属性来改变文件的访问权限设置
修改标签和注解
在pod运行时修改标签和注解，当标签和注解被修改后，kubernetes会更新存有相关信息的文件，从而使pod可以获取最新的数据，这也是为什么不能通过环境变量方式暴露标签和注解的原因，在环境变量方式下，一旦标签和注解被修改，新的值将无法暴露
在卷的定义中引用容器级的元数据
当暴露容器级的元数据时，必须指定引用资源字段对应的容器名称，如容器可使用的资源限制或资源请求（使用字段resourceFieldRef），这样做的理由是，因为我们对于卷的定义是基于pod级别，而不是容器级别的。当我们引用卷定义某一个容器的资源字段时，需要明确说明引用的容器名称。这个规则对于只包含单容器的pod同样适用。
使用卷的方式来暴露的资源请求和使用限制比环境变量的方式稍显复杂，但好处是可以传递一个容器的资源字段到另一个容器（两个容器必须处于同一个pod）。使用环境变量方式，一个容器只能传递他自身资源申请求和限制的信息
何时使用downwardAPI方式
downward API方式使得应用独立于kubernetes。这一点在处理部分数据已在环境变量中的现有应用时特别有用。Downward API方式使得我们不必通过修改应用，会使用shell脚本获取数据再传递给环境变量的方式来暴露数据。
不过，通过downward API的方式获取元数据相当有限，如果获取更多元数据，需要使用直接访问kubernetes API服务器的方式。