1.在Kubernetes上运行一个 Python 应用程序
2.技术干货kubectl源码阅读—get命令
3.听GPT 讲K8s源代码--cmd(一)
4.k8s要学多久
5.三种不同场景下的 Kubernetes 服务调试方法
6.kubectlapply和create的区别?
在Kubernetes上运行一个 Python 应用程序
在Kubernetes上部署Python应用程序
Kubernetes是一个开源平台，用于部署、维护和扩展容器化应用程序。它提供了一个简单且强大的框架，帮助用户管理容器化Python应用，同时保持可移植性、溯源码扎带可扩展性和自我修复能力。
不论Python应用的复杂度如何，Kubernetes都能高效地部署和伸缩它们，并在资源有限的环境中进行滚动升级。本文将引导你完成在Kubernetes上部署简单Python应用的过程，包括必需条件、容器化Python应用、创建容器镜像、发布镜像、使用持久卷等步骤。
部署前，确保你已安装Docker和kubectl，并准备好源代码。Docker是一个构建和承载已发布应用的平台，通过其官方文档进行安装验证。kubectl是用于在Kubernetes集群上运行命令的命令行工具。
部署应用至Kubernetes要求应用为容器化形式。本文将回顾Python应用的容器化过程，解释容器化及其优势，并参考Roman Gaponov的文章为Python代码创建容器。
接下来，需要读源码我们将通过Dockerfile构建Python容器镜像。Dockerfile包含运行示例Python代码的指令，使用Python 3.5作为开发环境。使用命令构建镜像，然后发布到私有或公共云仓库，如Docker Hub。
在发布镜像前，为它添加版本号。对于使用不同云注册中心的情况，可参考其相关信息。在本教程中，我们将使用Docker Hub。
使用Docker命令将镜像推送到云仓库。对于Kubernetes，将使用CephFS作为持久卷提供商。创建文件以配置CephFS存储，并使用kubectl将持久卷添加到Kubernetes集群。
部署Python应用至Kubernetes的最后一步是创建服务文件和部署文件。使用提供的内容创建这些文件，然后通过kubectl将应用部署到Kubernetes集群。
验证应用是否成功部署，通过检查运行的服务。Kubernetes可简化未来应用部署的复杂性。
欲深入了解Python知识，推荐Nanjekye的书，包含在Python 2和3上编写可靠代码的javaee导入源码完整方法，以及如何转换Python 2代码以在Python 2和3上稳定运行的详细示例。
本文由Joannah Nanjekye撰写，是一位充满激情的飞行员，专注于用代码解决问题。本文译者为qhwdw，校对由wxy完成。
了解更多关于作者的信息
来源：opensource.com/article/...
作者：Joannah Nanjekye
译者：qhwdw
校对：wxy
本文由LCTT原创编译，Linux中国荣誉推出
技术干货kubectl源码阅读—get命令
技术解析kubectl源码解析：get命令的关键逻辑 在深入研究kubectl源码时，get命令的实现揭示了几个关键点。首先，kubectl的子命令结构由cobra包的Command结构体定义，它包含了子命令集合和核心执行逻辑。get、describe和create等是kubectl的子命令，它们在command.Execute()方法中通过参数查询并执行相应的逻辑。 get命令的核心在于一个接收和保存参数的结构体，结合pflag包。具体到get命令，关键在于o.Run方法，其中kubectl通过一个名为r的构建器来访问接口获取数据。这个过程使用了访问者模式，r.visitor链式调用了多个装饰器，如FlattenListVisitor和Selector，从而决定了输出的表头和状态信息。 在数据获取过程中，kubectl调用的ise隐藏源码接口并不普通，而是带有特殊的header 'as=Table'。这个header的添加是在client的构建和传递过程中通过requestTransforms回调实现的。通过追踪，我们可以发现restMapper是如何与Builder对象结合的，进而找到资源别名的转换逻辑。 最终，kubectl通过e.discoveryClient.ServerGroupsAndResources()方法获取到所有k8s资源的别名，从而实现了从get po到get svc等命令的别名转换。kubectl的get命令不仅动态调整表头，还能够处理各种状态信息，这些都是通过其底层的接口调用和数据处理机制实现的。听GPT 讲K8s源代码--cmd(一)
在 Kubernetes（K8s）的cmd目录中，包含了一系列命令行入口文件或二进制文件，它们主要负责启动、管理和操控Kubernetes相关组件或工具。这些文件各司其职，如：
1. **check_cli_conventions.go**: 该文件作用于检查CLI约定的规范性，确保命令行工具的一致性和易用性。它提供函数逐项验证命令行工具的帮助文本、标志名称、标志使用、输出格式等，输出检查结果并提供改进意见。
2. **cloud_controller_manager**: 这是启动Cloud Controller Manager的入口文件。Cloud Controller Manager是Kubernetes控制器之一，负责管理和调度与云平台相关的cudnn caffe源码资源，包括负载均衡、存储卷和云硬盘等。
3. **kube_controller_manager**: 定义了NodeIPAMControllerOptions结构体，用于配置和管理Kubernetes集群中的Node IPAM（IP地址管理）控制器。此文件包含配置选项、添加选项的函数、应用配置的函数以及验证配置合法性的函数。
4. **providers.go**: 用于定义和管理云提供商的资源。与底层云提供商进行交互，转换资源对象并执行操作，确保Kubernetes集群与云提供商之间的一致性和集成。
5. **dependencycheck**: 用于检查项目依赖关系和版本冲突，确保依赖关系的正确性和没有版本冲突。
6. **fieldnamedocs_check**: 检查Kubernetes代码库中的字段名称和文档是否符合规范，确保代码的规范性和文档的准确性。
7. **gendocs**: 生成Kubernetes命令行工具kubectl的文档，提供命令的用法说明、示例、参数解释等信息，方便用户查阅和使用。
8. **genkubedocs**: 生成用于文档生成的Kubernetes API文档，遍历API组生成相应的API文档。
9. **genman**: 用于生成Kubernetes命令的man手册页面，提供命令的说明、示例和参数等信息。
. **genswaggertypedocs**: 生成Kubernetes API的Swagger类型文档，提供API的详细描述和示例。
. **genutils**: 提供代码生成任务所需的通用工具函数，帮助在代码生成过程中创建目录和文件。
. **genyaml**: 为kubectl命令生成YAML配置文件，方便用户定义Kubernetes资源。
. **importverifier**: 检查代码中的导入依赖，并验证其是否符合项目中的导入规则。
. **kube_apiserver**: 实现kube-apiserver二进制文件的入口点，负责初始化和启动关键逻辑。
. **aggregator**: 为聚合API提供支持，允许用户将自定义API服务注册到Kubernetes API服务器中，实现与核心API服务的集成。
这些文件共同构建了Kubernetes命令行界面的底层逻辑，使得Kubernetes的管理与操作变得更加高效和灵活。
k8s要学多久
学习Kubernetes的基础知识并不困难，特别是如果你已经有半个月的Docker使用经验。主要挑战在于封装镜像时需要考虑挂载、拆分和启动检测等问题。
安装Kubernetes本身就是一个复杂的过程。前期的安装尝试包括自动化安装、手动安装、脚本自动化安装、Ansible安装和离线安装，这耗费了我大约一个月的时间。随后，我遇到了一些环境和网络问题，导致pod一直重启，这个问题持续了大约两个月。我尝试更换为实体机，问题有所缓解，但最终估计还是网络不稳定导致。
学习kubectl命令和Kubernetes的基本组件（如pod、svc、deployment、daemonset、statefulset、headlessService、rc、kube-proxy、rbac等）也是需要花费时间的。我花了大约一个月时间来理解这些组件的原理，尤其是新版本的rbac权限问题。Kubernetes的复杂性主要在于其体系架构，一旦理解了架构，就理解了大部分的内容。
在对开源工程domeos进行研究后，我使用了两个月时间来调研该开源工程的源码，以及它自带的一些小米open-falcon监控插件、webssh等插件。这些研究涉及使用Springboot开发，连接Kubernetes环境，部署和监控基本应用。
为了调优日志和监控，我又花费了一个多月的时间来调研一些开源产品，如efk日志插件、Prometheus与heaspter监控组件、habor镜像仓库等。
最后，我开始使用Helm这一编排工具，根据Hadoop的过程改造公司的一个mpp产品，并实现一键式部署。这同样花费了一个多月的时间。在这一过程中，我还研究了Hadoop的扩容、亲和性、带状态应用部署等问题，以及数据删除问题。
三种不同场景下的 Kubernetes 服务调试方法
在开发和调试 Kubernetes 生产环境下的服务时，会遇到各种调试需求。本文将介绍三种不同场景下的解决方案和相应的工具。基本配置
假设我们有三个服务：service-front 面向外部，通过服务暴露；service-front 后端是 service-middle，后者又依赖 service-back。通信通过 Kubernetes 服务进行。安装配置如下： 源代码可在：github.com/erkanerol/se...工具1：kubectl port-forward
场景：开发者希望在不影响其他服务的情况下，通过 service-back 直接发送请求并查看结果，但 service-back 不对外公开。 解决方案：使用 kubectl 的 port-forward 功能创建本地到集群的隧道。 步骤：在终端运行：kubectl port-forward service-back: localhost:
在另一个终端中，尝试用 curl 访问 localhost: 来验证连接。
工具2：kubefwd
场景：开发者希望在本地 IDE 中设置断点调试 service-front，但 service-front 和依赖服务难以本地模拟。 解决方案：kubefwd 可以批量端口转发并管理本地 DNS，简化配置。 步骤：运行：kubefwd service-front:
使用 sudo，配置 KUBECONFIG，运行本地 front 应用并设置断点。
在集群中测试服务交互。
工具3：telepresence
场景：开发者需要在本地调试 service-middle，同时 service-middle 依赖 service-back，并且集群环境不易模拟。 解决方案：telepresence 提供双向通道，支持本地服务与集群服务间的调试。 步骤：删除集群中的 service-middle，运行 telepresence。
本地运行 middle 应用并设置断点。
通过集群临时 Pod 发送请求到 service-front。
总结：对于不暴露服务的访问，kubectl port-forward 足够。
本地调试时，kubefwd 管理 DNS，提供单向通道。
需要双向通道和依赖服务调试时，使用 telepresence。
kubectlapply和create的区别?
在操作Kubernetes集群时，常使用kubectl或client-go等SDK进行资源管理。面对一个问题，即在已部署资源如deployment上使用kubectl apply与kubectl edit的区别。
假设在集群中部署了特定的deployment资源，该资源通常通过模板渲染后使用kubectl apply命令进行更新。若直接在集群上使用kubectl edit增加额外配置项，然后通过模板继续apply更新（不包含edit新增的部分），那么edit命令增加的部分会否在下次apply时被置空？
解答是，不会置空。具体来说，kubectl apply在计算最终patch数据时，需要删减的部分基于集群中当前资源的last-apply-anno与要apply资源的比较获得。与之类似，oam实现的kubevela在deployment上维护oam-last-apply，因此原理相同。值得注意的是，从kubectl apply迁移到oam时，两者维护的last-apply-anno不一致可能导致的问题。
若频繁遭遇patch失败（client-go/kubectl patch），但kubectl apply无此问题，建议深入理解kubectl apply的实现逻辑。一篇关于其源码分析的文章可供参考。
