作为一个管理跨多台主机的集合体应用程序的开源系统，源自Google十年容器化基础架构Borg的Kubernetes（下文简称K8s）提供了部署、维护和扩展应用程序的基本机制。因为K8s具有的轻量级，消耗资源小，开源，弹性伸缩和负载均衡等特点，使其已经成为了业内的通用PaaS平台。
介绍K8s架构，功能以及应用的文章可谓汗牛充栋，而本文尝试用国际化视角（I18n）来解读和剖析K8s。先来关注K8s的各部分组件，其中包括etcd（一个可信赖的分布式键值对存储服务，能否为整个分布式集群存储一些关键数据，协助分布式集群的正常运转，是K8s的持久化方案，存储K8s集群所有重要信息），kubectl（命令行接口，用于对 K8s 集群运行命令），scheduler（负责介绍任务，选择合适的节点进行任务分配），api server（是一切服务访问的入口，负责把来自scheduler的任务写入etcd中），replication controller（控制器，维护副本的期望数目），kuberlet（通过Container Runtime Interface和docker进行交互，操作docker来创建对应的容器，实现pod的生命周期管理），kube proxy（pod间的访问以及负载均衡，通过操作firewall来实现pod映射），pod和node等。
其他常用插件还包括了CoreDNS（为奇群中的SVC创建一个域名IP的对应关系解析），IngressController（官方只实现了四层代理，Ingress可以实现七层），Federation（提供一个跨集群中心多K8s统一管理功能），Prometheus（提供K8s的集群监控能力），ELK（提供K8s集群日志统一分析介入平台）和dashboard等。
考虑到这些K8s核心组件基本上已经对非英文字符的输入输出进行了限制，只接受a-zA-Z0-9这样的字符。即便没有限制的地方，也提出了行业规定对命名进行了统一。导致L1相关的检查点全部失效，与I18n的部分只剩下了图中红框所示的web UI，这其中又可分为两个派生的开源项目，分别是Octant（一个基于web的、高度可扩展的平台，供开发人员更好地理解Kubernetes集群的复杂性）和Harbor（一个开源的容器映像注册表，它使用基于角色的访问控制来保护映像，扫描映像中的漏洞，并将映像标记为受信任）。
对于Octant而言，其主要的实现语言和技术如下表。
|
|
Language |
Version |
Framework |
Version |
|
Frontend |
TypeScript |
3.7.5 |
Angular Clarity |
9.0 3.0 |
|
Backend |
Go |
1.13.3 |
|
|
L1因为大部分输入区域已经进行了限制，其余为限制的区域也统一按照行业规范进行命名，所以跟I18n的相关度可以被认为是零。L2中包含的locale，date-time，number等也都未进行处理，依然保持着en-US的格式，但作为一个并非面向最终用户的PaaS平台，这些问题依然无伤大雅，可以认为用户受影响的程度为很低。而L3中layout已经基本满足了I18n要求，但所有UI string依然保持着硬编码，对用户的影响程度可以设置为低。下图为使用了UI validator后的UI效果。
再看Harbor，其主要的实现语言和技术如下。
|
|
Language |
Version |
Framework |
Version |
|
Frontend |
TypeScript |
3.5 |
Angular |
8.2 |
|
Backend |
Go Python |
1.13.3 3.7 |
|
|
L1跟Octant一致，因为限制和统一行业命名规范的存在，可以认为与I18n不想关。Harbor在部署过程中提供了6个locale选择，分别是英文，简体中文，法文，巴西葡萄牙语，土耳其语。date-time格式也按照对应个locale进行了格式化输出，但number格式，单位等在二层的处理过程中被忽略了，整体看，L2的现状对用户的影响程度很低。在开源社区的帮助下，所有UI string都已经被提取到了JSON文件中（例如zh-cn.json），不存在硬编码问题。Layout也完美的符合了I18n设计与布局要求，三层的实现现状对用户完全没有影响，如下图所示。
最后附上K8s架构图，希望对各位国际化开发和测试的从业者们有所帮助。