生产环境使用K8s一年后,我们总结了这些经验教训
k8s面试题超详细总结
k8s面试题超详细总结一个目标：容器操作；两地三中心；四层服务发现；五种Pod共享资源；六个CNI常用插件；七层负载均衡；八种隔离维度；九个网络模型原则；十类IP 地址；百级产品线；千级物理机；万级容器；相如无亿，k8s有亿：亿级日服务人次。
一个目标：容器操作Kubernetes（k8s）是自动化容器操作的开源平台。
这些容器操作包括：部署、调度和节点集群间扩展。
具体功能：自动化容器部署和复制。
实时弹性收缩容器规模。
容器编排成组，并提供容器间的负载均衡。
调度：容器在哪个机器上运行。
组成：kubectl：客户端命令行工具，作为整个系统的操作入口。
kube-apiserver：以REST API服务形式提供接口，作为整个系统的控制入口。
kube-controller-manager：执行整个系统的后台任务，包括节点状态状况、Pod 个数、Pods和Service的关联等。
kube-scheduler：负责节点资源管理，接收来自kube-apiserver创建Pods任务，并分配到某个节点。
etcd：负责节点间的服务发现和配置共享。
kube-proxy：运行在每个计算节点上，负责Pod网络代理。
定时从etcd获取到service信息来做相应的策略。
kubelet：运行在每个计算节点上，作为agent，接收分配该节点的Pods任务及管理容器，周期性获取容器状态，反馈给kube-apiserver。
DNS：一个可选的DNS服务，用于为每个Service对象创建DNS记录，这样所有的Pod就可以通过DNS访问服务了。
下面是k8s的架构拓扑图：两地三中心两地三中心包括本地生产中心、本地灾备中心、异地灾备中心。
两地三中心要解决的一个重要问题就是数据一致性问题。
k8s使用etcd组件作为一个高可用、强一致性的服务发现存储仓库。
用于配置共享和服务发现。
它作为一个受到Zookeeper和doozer启发而催生的项目。
除了拥有他们的所有功能之外，还拥有以下4个特点：简单：基于HTTP+JSON的API让你用curl命令就可以轻松使用。
Kubernetes(K8s)安全加固与漏洞修复
Kubernetes（K8s）安全加固与漏洞修复Kubernetes（简称K8s）作为一个开源的容器编排平台，能够提供高度可扩展的部署、自动化管理和伸缩性操作等功能。
然而，Kubernetes也存在一些安全隐患和漏洞，如未经授权的访问、不安全的容器配置、网络安全威胁等问题。
为了保障Kubernetes集群的安全性，我们需要进行安全加固与漏洞修复。
本文将探讨Kubernetes安全加固的重要性以及一些常见的漏洞修复措施。
一、Kubernetes安全加固的重要性在现代云计算环境中，Kubernetes已经成为最受欢迎的容器编排工具之一。
然而，由于其开放性和高度可编程性，Kubernetes也面临着一些安全挑战。
一个未经加固的Kubernetes集群可能会受到攻击，导致敏感数据泄露、应用程序异常、拒绝服务等问题。
因此，进行Kubernetes安全加固变得尤为重要。
实施Kubernetes安全加固措施可以帮助企业识别和消除潜在的安全风险，以确保集群的安全性。
同时，适当的安全加固还能增加集群的稳定性和性能，提高系统的可用性和可靠性。
二、Kubernetes安全加固的措施下面列举了一些常见的Kubernetes安全加固措施，旨在帮助您提高Kubernetes集群的安全性。
1.健全的访问控制策略通过实施细粒度的访问控制策略，可以限制对Kubernetes集群和敏感资源的访问。
这可以通过使用Role-Based Access Control（RBAC）进行权限管理、使用网络策略来控制容器之间的通信以及使用Pod Security Policies（PSP）来限制容器的特权操作等方式来实现。
2.更新和维护集群组件定期更新和维护Kubernetes集群中的组件，可以修复一些已知的漏洞并提高系统的安全性。
同时，确保使用最新的Kubernetes版本，以及合适的安全补丁和修复程序。
3.安全的容器配置在部署容器时，应该采取一些安全措施，如限制容器的权限、使用安全的镜像、避免将敏感数据直接嵌入镜像等。
Kubernetes(K8s)性能优化与调优实践
Kubernetes（K8s）性能优化与调优实践Kubernetes（K8s）是一个开源的容器编排平台，被广泛应用于构建和管理容器化应用。
然而，随着应用规模的不断增长，性能问题已经成为许多企业面临的挑战之一。
本文将讨论Kubernetes性能优化与调优的实践方法，旨在帮助企业充分发挥Kubernetes的潜力，并提升应用的性能和可靠性。
一、资源调整Kubernetes允许用户对容器的资源进行调整，以确保每个容器都能得到足够的计算和内存资源。
在优化性能时，我们可以通过以下几个方面进行调整：1.1 CPU资源调整在Kubernetes中，可以通过配置容器的CPU限制和请求值来控制其使用情况。
需要根据应用的需求和实际情况来调整这些值。
合理设置CPU限制和请求值可以避免容器之间的资源争用，从而提升整体性能。
1.2 内存资源调整内存资源的合理调整同样重要。
通过设置容器的内存限制和请求值，可以确保容器有足够的内存可用。
如果内存使用超出限制，Kubernetes会执行相应的动作，例如终止容器或者触发OOM（Out of Memory）事件。
合理配置内存资源将有助于提升应用的性能和稳定性。
二、调度策略Kubernetes的调度策略对应用性能也有一定的影响。
根据具体场景和需求，可以采取以下方式进行优化：2.1 Pod亲和性调度Kubernetes允许通过设置节点的标签和Pod的亲和性规则，将相关的Pod调度到同一节点上。
这样可以减少跨节点的网络通信，提升应用的性能。
例如，可以将需要频繁通信的服务部署在同一节点上，避免网络延迟的影响。
2.2 Pod反亲和性调度类似地，反亲和性调度可以将相关的Pod避免部署在同一节点上。
这在一些需要高可用性和容灾的场景下尤为重要。
通过将相互依赖的服务部署到不同节点上，可以提高系统的可靠性和稳定性。
三、网络配置网络配置也是Kubernetes性能优化的一项重要任务。
以下几个方面可以被优化：3.1 负载均衡配置Kubernetes支持多种负载均衡方式，例如IPVS、iptables和kube-proxy等。
Kubernetes(K8s)集群升级与版本管理策略
Kubernetes（K8s）集群升级与版本管理策略Kubernetes（K8s）是一个开源的容器编排平台，广泛应用于云原生应用的部署和管理。
对于长期运行的Kubernetes集群，升级和版本管理是非常关键的。
本文将探讨Kubernetes集群升级的最佳实践和版本管理策略。
一、为什么需要升级Kubernetes集群？1. 安全性：Kubernetes的升级通常会修复已知的安全漏洞和问题，并提供更强的安全性保障。
2. 特性增强：每个Kubernetes版本都会引入新的功能和改进，升级可以获得这些新特性，提升集群的性能和功能。
3. 缺陷修复：Kubernetes的每个版本都会修复一些已知的缺陷和问题，升级可以消除这些潜在的风险。
二、升级Kubernetes集群的最佳实践1. 版本选择：在升级之前，需要仔细评估当前集群的版本和可用的最新版本。
了解新版本的功能和改进，并与集群中正在运行的工作负载进行兼容性测试。
2. 备份数据：在进行任何升级操作之前，务必备份Kubernetes集群中的重要数据。
这样可以在出现问题时可以快速回滚到之前的状态。
3. 先升级较低级别的组件：一个Kubernetes集群通常由多个组件组成，如kube-apiserver、kube-controller-manager、kube-scheduler等。
在进行版本升级时，建议先从较低级别的组件开始，逐步升级到更高级别的组件，以确保整个集群的稳定性。
4. 并行升级：在较大规模的集群中，可以考虑并行升级的方式。
即同时升级多个集群节点，以减少升级时间。
但需要注意控制资源消耗，避免影响集群的稳定性。
5. 验证升级：完成版本升级后，需要进行验证操作，确保升级没有引入新的问题。
可以通过自动化测试、功能测试和性能测试来验证集群的正确性和可用性。
三、版本管理策略1. 使用官方版本：建议使用官方发布的稳定版本。
这些版本经过严格的测试和验证，通常比较可靠并且有广泛的社区支持。
k8s 必须要会的知识点
k8s 必须要会的知识点K8s是一款领先的容器编排平台，它可以帮助用户简化应用程序的部署、扩展和管理。
在使用K8s之前，必须掌握一些基本知识点。
以下是关于K8s必须要会的知识点。
一、K8s的基础概念1.1 K8s架构K8s架构包括Master节点和Worker节点。
Master节点负责管理整个集群，包括调度、监控、存储等任务；Worker节点负责承载容器运行。
1.2 K8s对象K8s中有很多对象，如Pod、Service、Deployment等。
每个对象都有自己的生命周期和状态，并且可以通过API Server进行操作。
1.3 PodPod是最小的可部署单元，它可以包含一个或多个容器，并共享同一个网络命名空间和存储卷。
1.4 ServiceService提供了一个稳定的IP地址和DNS名称来访问一组Pod，可以将请求路由到不同的Pod上。
1.5 DeploymentDeployment用于管理Pod副本数量和更新策略，可以实现滚动升级和回滚操作。
二、K8s的安装与配置2.1 安装Docker在安装K8s之前，必须先安装Docker作为底层容器引擎。
可以通过官方文档或Docker官网进行安装。
2.2 安装K8sK8s可以通过多种方式进行安装，如二进制文件、kubeadm工具、各种发行版的包管理器等。
建议使用kubeadm进行安装，因为它是一个官方推荐的工具，并且可以自动完成大部分配置。
2.3 配置K8s集群在安装完K8s后，需要对集群进行一些基本配置，如设置网络插件、创建Pod网络等。
可以参考官方文档或相关教程进行配置。
三、K8s的常用操作3.1 创建和管理Pod可以通过kubectl命令创建和管理Pod，如创建一个Pod、查看Pod 状态、删除Pod等。
3.2 创建和管理Service同样可以通过kubectl命令创建和管理Service，如创建一个Service、查看Service状态、删除Service等。
k8s lifecycle用法
文章内容如下：一、什么是k8s lifecycle？Kubernetes（简称k8s）是一个开源的容器编排引擎，它可以自动化地部署、扩展和操作应用程序容器。
在使用k8s时，我们经常会接触到k8s lifecycle，它是指Kubernetes中容器生命周期的管理方式。
容器生命周期包括容器的创建、启动、暂停、删除等阶段，而k8s lifecycle用法则是对容器在这些阶段进行管理和控制的一种方式。
二、k8s lifecycle用法的基本概念在k8s中，我们可以通过定义Pod模板的方式来控制容器的生命周期。
在Pod模板中，我们可以使用一些特殊的字段来定义容器在不同生命周期阶段的行为。
这些字段包括：preStop、lifecycle中的postStart 和preStop等。
通过定义这些字段，我们可以实现在容器启动前、启动后和停止前执行特定的操作，以实现对容器生命周期的精细控制。
三、k8s lifecycle用法的常见应用场景1. 容器启动前的操作在某些情况下，我们可能需要在容器启动前执行一些初始化操作，比如检查环境变量、配置文件的加载等。
此时，可以通过在Pod模板的lifecycle字段中定义postStart来实现在容器启动后执行特定的命令或脚本，以确保容器启动后能够正常运行。
2. 容器停止前的操作类似地，有时我们希望在容器停止前执行一些清理操作，比如保存数据、关闭连接等。
这时，可以通过在Pod模板的lifecycle字段中定义preStop来实现在容器停止前执行特定的命令或脚本，以确保容器停止时能够正常释放资源。
四、个人观点和理解对于k8s lifecycle用法，我认为它是Kubernetes中非常重要的一部分。
通过对容器生命周期的管理和控制，我们可以更加精细地调控容器的行为，从而提高应用程序的稳定性和可靠性。
在实际应用中，我建议多加利用k8s lifecycle的功能，以确保容器在不同阶段能够按照我们的期望进行操作，从而更好地满足业务需求。
k8s yaml 变量替换最佳实践
标题：深度探讨k8s yaml变量替换最佳实践在当今云原生应用开发中，Kubernetes（简称k8s）已经成为了一个非常流行的容器编排评台。
在使用Kubernetes进行应用部署时，yaml文件是必不可少的配置文件格式。
然而，在实际应用过程中，我们经常需要对yaml文件中的变量进行替换，以满足不同环境下的需求。
本文将深度探讨k8s yaml变量替换的最佳实践，以帮助读者更好地理解和应用该技术。
一、为什么需要yaml变量替换在实际应用部署中，我们通常需要适配不同环境下的配置信息、密码、位置区域等，而且这些配置信息可能会随着环境的变化而变化。
在开发环境中，我们可能需要连接本地的数据库，而在测试或生产环境中，则需要连接不同的数据库。
此时，我们就需要使用yaml变量替换来动态地适配不同环境下的配置信息。
二、yaml变量替换的基本原理yaml文件中的变量替换可以通过引入外部的变量文件或者环境变量来实现。
在Kubernetes中，我们常用的替换方式包括使用ConfigMap、Secrets以及使用helm等方式。
1. 使用ConfigMap和Secrets通过定义ConfigMap和Secrets，在yaml文件中引用这些变量，从而实现对yaml配置文件中变量的替换。
这种方式比较灵活，可以在kubectl apply时动态注入配置信息，并且不需要每次都修改yaml文件。
2. 使用helmHelm是Kubernetes的包管理工具，提供了一种简便的方式来管理Kubernetes应用的charts。
在使用helm时，可以通过定义values文件来存放配置信息，并在模板文件中引用这些变量来实现替换。
这种方式在大型部署中更为常用，可以实现更灵活和复杂的变量替换。
三、yaml变量替换的最佳实践1. 将常变化的配置信息抽离为ConfigMap或Secrets，并在yaml文件中引用这些变量。
这样可以更好地管理和维护配置信息，避免每次修改yaml文件。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
生产环境使用K8s一年后，我们总结了这些经验教训2015年初，我们计划为开发团队搭建一套全新的部署平台，在此之前我们使用的是Amazon EC2。
尽管AWS-based steup我们一直用得很好，但使用自定义脚本和工具自动化部署的设置，对于运维以外的团队来说不是很友好，特别是一些小团队——没有足够的资源来了解这些脚本和工具的细节。
这其中的主要问题在于没有“部署单元（unit-of-deployment）”，该问题直接导致了开发与运维之间工作的断层，而容器化趋势看上去是一个不错的方案。
如果你还没有做好将Docker和Kubernetes落地到生产环境的准备，不妨参考参考我们的经验。
我们已经在生产环境使用kubernetes一年多了。
从容器和容器编排工具开始我们相信容器会是未来最主流的部署格式，这项技术让应用封装变得简单了许多。
类似于Docker之类的工具提供了实际的容器，但我们还需要复制、故障排除等工具，以及可实现自动部署到多台机器的API，好让容器技术发挥出最大的作用。
在2015年初，Kubernetes、Docker Swarm等集成工具还不成熟，仅提供alpha版本。
不过我们还是决定试一试，并选择了Docker Swarm。
我们用Docker Swarm来处理网络，利用Ambassador模式和一组脚本来实现自动化部署。
这种方式难度之大，超乎想象，我们也因此收获了第一个教训：容器集成、网络、部署自动化是非常棘手的问题。
好在我们很快意识到了这一点，并决定将筹码压在Kubernetes身上——一款由Google、Red Hat、Core OS及一些对大规模部署颇有见地的组织提供支持的集成工具。
通过Kubernetes实现负载均衡使用Kubernetes，需要对pods、services、replication controller等概念了然于心。
好消息是，包括Kubernetes官方文档在内，网络上有海量资源，可以帮助你快速上手。
成功建立并运行Kubernetes集群后，即可通过kubectl （Kubernetes CLI）部署应用了。
然而当我们想要自动化部署时，却发现光有kubectl是不够的。
不过，在此之前我们需要解决另一个问题：如何从Internet访问部署的应用？部署前的服务有一个IP地址，但这个地址仅在Kubernetes 集群中可用。
这意味着无法通过网络访问该服务！在Google Cloud Engine上运行时，Kubernetes会自动配置一个负载均衡用以访问应用；如果不在Google Cloud Engine 上运行（比如我们），那就需要做一些额外的工作来获得负载均衡了。
直接在主机端口上开放服务是一个可行的解决方案（很多人一开始的确是这么做的），但我们发现，这样的做法等于放弃了Kubernetes所提供的许多好处。
如果我们依赖主机上的端口，部署多个应用时会遇到端口冲突。
另外这样的做法会加大扩展集群和更换主机的难度。
二级负载均衡器配置我们发现，解决以上问题的更好办法，是在Kubernetes集群前配置负载均衡器，例如HAProxy或者NGINX。
于是我们开始在AWS上的VPN中运行Kubernetes集群，并使用AWS ELB将外部web流量路由到内部HAProxy集群。
HAProxy为每个Kubernetes服务配置了“后端”，以便将流量交换到各个pods。
这种“二级负载均衡器配置”主要也是为了适应AWS ELB相当有限的配置选项。
其中一个限制是，它不能处理多个vhosts。
这也是我们同时使用HAProxy的原因。
只使用HAProxy（不用ELB）也能工作，只不过需要你在DNS级别解决动态AWS IP地址问题。
图1:我们的“二级负载均衡器配置流程“在任何情况下，创建新的Kubernetes服务，我们都需要一种机制动态重新配置负载均衡器（在我们的例子中是HAProxy）。
Kubernetes社区目前正在开发一个名为ingress的功能，用来直接从Kubernetes配置外部负载均衡器。
可惜的是，目前开发工作还未完成。
过去一年，我们采用的是API配合一个小的开源工具来配置负载均衡。
配置负载均衡首先，我们需要一个地方存储负载均衡器配置。
负载均衡器配置可以存储在任何地方，不过因为我们已经有etcd可用，就把这些配置放在了etcd里。
我们使用一个名为“confd”的工具观察etcd中的配置变动，并用模板生成了一个新的HAProxy配置文件。
当一个新的服务添加到Kubernetes，我们向etcd中添加一个新的配置，一个新的HAProxy配置文件也就此产生。
不断完善的KubernetesKubernetes中仍然存在众多待解决的问题，很多开发者在社区上、设计文档中讨论解决这些问题的新功能，但开发适用于每一个人的解决方案是需要时间的。
不过从长远来看，这也是一件好事，用shortcut的方式设计新功能很多时候会适得其反。
当然，问题的存在并不意味着我们现在所使用的Kubernetes功能有限。
配合API，Kubernetes几乎可以完成你想要的一切。
等Kubernetes增加新功能后，我们再用标准方案替代自己的解决方案不迟。
话说回来，在我们开发了用于负载均衡的解决方案后，另一项挑战接踵而至：蓝绿部署（Blue-green deployments）。
Kubernetes上的蓝绿部署蓝绿部署是一种不中断服务的部署。
与滚动更新不同，蓝绿部署在旧版本仍然正常工作的情况下，通过启用一个运行着新版本的副本集群来实现更新。
当新版本的副本集群完全启动并运行时，负载均衡器配置才会更改并将负载切换到新版本上。
这种方式的好处是，永远保持至少一个版本的应用正常运行，减少了处理多个并发版本带来的复杂性。
蓝绿部署在副本数量很少时也能很好的工作。
图2:Kubernetes下的蓝绿部署图2展示了“Deployer“如何编排部署。
基于Apache License，并作为Amdatu umbrella project的一部分，我们开源了这个组件的实现，供大家参考使用。
另外，这个组件带web UI，可以用来配置部署。
这种机制的一个要点是在重新配置负载均衡器之前，执行在pods上的运行状态检查。
我们希望每部署的每一个组件都能提供状态检查。
目前的做法通常是为每个组件添加一个通过HTTP访问的状态检查。
实现部署自动化有了Deployer，我们就可以把部署集成到构建流程中了。
我们的构建服务器可以在构建成功之后，将新的镜像推送到registry（如Git Hub），而后构建服务器可以调用新版本应用并自动部署至测试环境中。
同一个镜像也可以通过触发生产环境中的Deployer被推送上生产。
图3：容器化自动部署流程资源限制使用Kubernetes时，搞清楚资源限制很重要。
你可以在每个pod上配置资源请求和CPU／内存限制，也可以控制资源保证和bursting limits。
这些设置对于高效运行多个容器极为重要，防止容器因分配内存不足而意外停止。
建议尽早设置和测试资源限制。
没有限制时，看起来运行良好，不代表把重要负载放到容器中不会出现问题。
Kubernetes监控当我们快要搭建好Kubernetes时，我们意识到监控和日志在这个新的动态环境中非常重要。
当我们面对大规模服务和节点时，进入服务器查看日志文件是不现实的，建一个中心化的日志和监控系统需要尽快提上议程。
日志有很多用于日志记录的开源工具，我们使用的是Graylog和Apache Kafka（从容器收集摘录日志的消息传递系统）。
容器将日志发送给Kafka，Kafka交给Graylog进行索引。
我们让应用组件将日志打给Kafka，方便将日志流式化，成为易于索引的格式。
也有一些工具可以从容器外收集日志，然后发送给日志系统。
监控Kubernetes具备超强的故障恢复机制，Kubernetes会重启意外停止的pod。
我们曾遇到过因内存泄露，导致容器在一天内宕机多次的情况，然而令人惊讶的是，甚至我们自己都没有察觉到。
Kubernetes在这一点上做得非常好，不过一旦问题出现，即使被及时处理了，我们还是想要知道。
因此我们使用了一个自定义的运行状况检查仪表盘来监控Kubernetes节点和pod，以及包括数据存储在内的一些服务。
可以说在监控方面，Kubernetes API再次证明了其价值所在。
检测负载、吞吐量、应用错误等状态也是同样重要的，有很多开源软件可以满足这一需求。
我们的应用组件将指标发布到InfluxDB，并用Heapster去收集Kubernetes的指标。
我们还通过Grafana（一款开源仪表盘工具）使存储在InfluxDB中的指标可视化。
有很多InfluxDB／Grafana堆栈的替代方案，无论你才用哪一种，对于运行情况的跟踪和监控都是非常有价值的。
数据存储和Kubernetes很多Kubernetes新用户都有一个问题：我该如何使用Kubernetes处理数据？运行数据存储时（如MangoDB或MySQL），我们很可能会有持久化数据储存的需求。
不过容器一但重启，所有数据都会丢失，这对于无状态组件没什么影响，但对持久化数据储存显然行不通。
好在，Kubernetes具有Volume机制。
Volume可以通过多种方式备份，包括主机文件系统、EBS （AWS的Elastic Block Store）和nfs等。
当我们研究持久数据问题是，这是一个很好的方案，但不是我们运行数据存储的答案。
副本问题在大多数部署中，数据存储也是有副本的。
Mongo通常在副本集中运行，而MySQL可以在主／副模式下运行。
我们都知道数据储存集群中的每个节点应该备份在不同的volume中，写入相同volume会导致数据损坏。
另外，大多数数据存储需要明确配置才能使集群启动并运行，自动发现和配置节点并不常见。
同时，运行着数据存储的机器通常会针对某项工作负载进行调整，例如更高的IOPS。
扩展（添加/删除节点）对于数据存储来说，也是一个昂贵的操作，这些都和Kubernetes 部署的动态本质不相符。
决定不在生产环境数据存储上使用Kubernetes以我们的情况，在Kubernetes内运行数据存储没有想象中那么完美，设置起来也比其他Kubernetes部署复杂得多。
于是我们决定不在生产环境数据存储上使用Kubernetes，而是选择在不同的机器上手动启动这些集群，我们在Kubernetes内部运行的应用正常连接到数据存储集群。
所以说，没必要运行Kubernetes的一切，按自身情况与其他工具配合使用，会有意想不到的效果，比如我们的数据存储和HAProxy服务器。
未来看看我们现在的部署，可以负责任的说，Kubernetes的表现绝对是梦幻级的，而Kubernetes API更是自动化部署流程的利器。