小编bob*_*bef的帖子

所以我正在研究如何在我的案例中使用Kubernetes.我安装了它并玩了一下.

问题是当复制控制器启动几个副本时,它们的名称中有一个id:

1. 这个身份有多独特？它是kubernetes一生的独特之处吗？它是否在不同的kubernetes运行中是独一无二的(即如果我重新启动kubernetes)？
2. 如何将此ID传递给容器中的应用程序？我可以在yaml中指定某种模板,例如id会被分配给环境变量还是类似的？
3. 或者有没有办法让容器中的应用程序询问此ID？

用例的更多解释.我有一个应用程序在目录中写入一些会话文件.我想保证系统中会话ID的唯一性.这意味着如果一个应用程序实例在VM1上运行,另一个实例在VM2上运行,我想在app之前添加某种标识符,如app-1-dajk4l和app-2-dajk4l,其中app是应用程序的名称和1 ,2是实例标识符,它应该来自复制控制器,因为它是动态的,不能手动配置.dajk4l是一些标识符,如当前时间戳或类似标识符.

谢谢.

如果我的问题不准确,我很抱歉,因为我没有很多与Linux相关的经验.我目前正在从头开始构建一个Linux(主要是遵循linuxfromscratch.org 7.3版的指南).我遇到了以下问题:当我构建一个可执行文件时,它会获得一个名为ELF解释器的硬编码路径.

readelf -l program

显示类似的东西

[Requesting program interpreter: /lib/ld-linux.so.2]

我跟踪这个库ld-linux-so.2是glibc的一部分.我对这种行为不是很满意,因为它使二进制文件非常不可移植 - 如果我改变/lib/ld-linux.so.2的位置,可执行文件不再有效,我找到的唯一"修复"是使用patchelf来自NixOS的实用程序将硬编码路径更改为另一个硬编码路径.出于这个原因,我想链接到l​​d库的静态版本,但不会生成.所以这是我的问题,请你解释一下如何构建glibc以便生成ld-linux.so.2的静态版本,以后我可以链接到我的可执行文件.我不完全理解这个ld库的作用,但我认为这是加载其他动态库(或者至少是glibc.so)的部分.我想动态链接我的可执行文件,但我希望动态链接器本身静态内置到它们中,因此它们不依赖于硬编码路径.或者我希望能够使用类似于LD_LIBRARY_PATH的环境变量设置解释器的路径,也许是LD_INTERPRETER_PATH.目标是能够生成可移植的二进制文件,无论目录结构如何,它都可以在具有相同ABI的任何平台上运行.

一些可能相关的背景:我正在使用Slackware 14 x86来构建i686编译工具链,所以整体来说它都是x86主机和目标.我正在使用glibc 2.17和gcc 4.7.x.