 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
Kubernetes实战系列之一-原理篇
下载积分：2000
内容提示：Kubernetes实战系列之一-原理篇
文档格式：PPTX|
浏览次数：102|
上传日期： 09:10:23|
文档星级：
全文阅读已结束，如果下载本文需要使用
 2000 积分
下载此文档
该用户还上传了这些文档
Kubernetes实战系列之一-原理篇
官方公共微信【图文】Kubernetes实战系列之一-原理篇_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
Kubernetes实战系列之一-原理篇
上传于|0|0|暂无简介
大小：3.01MB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
【编者的话】本文为Core OS在其官方博客中发布的关于在Kubernetes 1.3的预览文章，介绍了目前Kubernetes新版本带来的新的引人入胜的特性和改进功能。本文作者为Mike Saparov，目前作为副总裁任职于CoreOS公司。
随着Kubernetes 1.3版本发布时间的临近，我们在这里分享一个关于CoreOS的文档，它可以帮助整个社区朝着这个重要的里程碑前进。Kubernetes是很多企业在早期环境中采用的并且能够持续推动其快速发展的一门技术。CoreOS团队选择专注于其在如下几个关键领域的发展，这将会进一步促进Kubernetes在世界各地的数据中心的使用：
Kubernetes API的身份验证和授权；改善了Kubernetes的安装和升级过程；通过引入一个初步的的集群元数据来优化其在scaling方面的改进；最后但并不是最重要的：rktnetes，使用rkt容器运行Kubernetes的一个初始发行版本。
身份验证和授权的Kubernetes APIs开发和运营人员喜欢Kubernetes能够仅仅通过一个API就可以为他们在集群环境中部署和管理容器。然而，在任何真实的环境中，访问控制是非常重要的。不是所有开发者都需要在CI集群上的超级用户权限。往往生产和部署需要更严格的权限控制，例如管理对单独的资源的访问，通过将用户分组在一起来简化管理，并且持续地审计用户的操作行为。Kubernetes需要一项新的验证（authN）和授权（authZ）机制以满足这些要求。
AuthN：连接的OpenID身份提供商（OpenID Connect Identity Providers）随着1.3版本的发布，CoreOS开发了一个 AuthProvider插件作为该版本的一部分，它允许OIDC身份提供商（IdPs）代表API服务器去验证kubectl和其他客户端。该OIDC AuthProvider可用于认证Kubernetes连接到任何OIDC身份提供商（IdP）。目前在云端，流行的OIDC 身份提供商（IdPs）包括有Google Identity和Amazon Cognito。
另一个OIDC身份提供商则是CoreOS的开源项目。Dex提供了一种灵活的方式来联合几个服务认证，包括现有的LDAP服务器和AD的LDAP接口。概括来讲，Kubernetes OIDC AuthProvider和Dex与企业现有的认证策略做了整合访问。
AuthZ：基于角色的访问控制（Role Based Access Control）CoreOS的开发者们也一致努力将基于角色的控制访问（Role
Based Access Control，RBAC）的工作整合进Kubernetes之中，这项功能也已经在v1.3中被引进并打上“alpha”标签了。该RBAC的实现是源于Red Hat的OepnShift项目。众所周知，基于用户角色的访问控制是大多数组织所熟悉的一种最佳实践，并且它允许管理员来规范用户根据其工作职能从而可以或者不可以做某些事。例如，属于“QA Team”角色的用户也许只有对于某一个生产集群中的节点的子集具有只读权限仅用于发布测试。
该RBAC系统建立于Kubernetes资源之上，可以让角色、权限和关系动态作用于first-class的API交互，将之前Kubernetes版本的authZ设施中的静态平面文件放置于其后面。该RBAC功能被添加进了Kubernetes 1.3中，简化了针对不同企业群体、团队或者会计制度的关于多租户环境中的创建情况。我们将在未来的某篇文章中进一步研究Kubernetes中的authN和authZ的原理以及特性。
简化Kubernetes安装和升级Kubernetes可以被认为是整个集群中的一个操作系统，并且在有些时候，这种复杂性可以在通过安装和管理它的各种组件的过程中来展现。目前推荐的更新方法基本上是——“创建一个新的集群，迁移工作负载，销毁旧的集群”——然而这并不是理想的运营团队所需要的。
由于CoreOS是该社区的一部分，因此我们在持续的努力，使得它的这些过程变得简单，并且关于以下的改进计划将会在Kubernetes 1.3中被合并：
针对AWS Kubernetes上精美的安装工具的大量的升级和改进，，为多种环境所写的手把手指南文档。支持“self-hosted”Kubelet，由于该技术已经成熟了，这将支持通过Kubernetes API本身来控制Kubernetes的无缝升级。Kubelet现在可以在的中运行了。这使得Kubelet部署新的容器镜像变得简单了。
etcd v3存储层你可能已经知道，Kubernetes依赖于开源的key-value store用于协调其群集状态。Kubernetes 1.3版本增加了对新的etcd v3后端的实验性支持。这些额外的etcd v3的设置为未来的Kubernetes可扩展性的工作打下了坚实的基础，例如运行更多的pods，更多的nodes并伴随着持续的高性能低负载特性。etcd的第三个版本同样带来了更多有用的功能集合，包括了多版本的并发控制（multi-version concurrency control，MVCC），高效率的多键交互（multiple key transactions），这将会有助于Kubernetes在未来的版本中达到甚至超越数千个节点。
在这个阶段，我们正在收集关于新的etcd的后端反馈，并且使用这些被分享的经验来推动并发布让其作为下一个生产环境的功能用于Kubernetes v1.4中。在接下来的几周中，我们将会逐步分享更多关于etcd v3的变化，从etcd v2迁移到v3，并且关于升级etcd v3和Kubernetes整合的系列的更多细节的文章。
rktnetes：在Kubernetes中的rkt容器引擎。该项工作内容可以被简称为rktnetes，它介绍了在Kubernetes中的新的容器引擎。CoreOS的开源rkt具有的一些有用的功能可以与Kubernetes和容器集群的整体理念保持一致，例如将pod作为控制单元，并采用了用于容器连接的简化。rktnetes可以让Kubernetes使用rkt于每个节点上取出并执行容器镜像。
在Kubernetes 1.3中，rktnetes是在“实验性”地追踪并准备在许多集群上运行。它的目标是在1.4版中变得“稳定”。在rktnetes上的工作有助于确保基本的Kubernetes界面的通用性，使得容器正常运行变得容易，这些容器都是专门用于交互的容器，并且不同的rumtime来适应某种架构、网站或者部署的特定需求。
Kubernetes 1.3及后期版本：加入确保互联网安全的使命对于上文所强调的，我们已经通过努力的工作和结合整个社区的巧妙思维使其他一些的基本特征成为了可能，Kubernetes 1.3是一个很实在的版本，并且CoreOS团队很荣幸地能成为其中的一员。大家可以在未来的几周关注此空间和关于Kubernetes v1.3的官方发布的细节，并且开始试着尝试rktnetes, etcd v3 API和很多其他新的功能。 如果你在类似于Kubernetes或者etcd在生产分布式系统的前沿做工作，。如果你有兴趣了解更多关于CoreOS如何帮助企业环境的Kubernetes部署，联系我们，可以为你创建一个私人的Kubernetes或尝试Tectonic的。
原文链接：（翻译：薛开成）
要回复文章请先或您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
Kubernetes实战系列之一-原理篇.pptx 33页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
需要金币：150 &&
Kubernetes实战系列之一-原理篇
你可能关注的文档：
··········
··········
Kubernetes培训叶伙荣（YeHuorong）Agenda扩容、容错、升级、负载均衡、服务发现安全和资源管控调度和控制K8S总体架构简介微服务监控、调试K8S总体架构K8S是一个基于容器技术的分布式系统，思想上的变革模块化思维（功能更加单纯，复用率高，高解耦）无需关心扩容、容错、负载均衡、通讯、安全、资源配额、服务发现等底层问题开发行为将由于“微服务”的理念而发生改变，部署工作更加便捷和自动化将运行环境打包，它使得应用程序在开发、测试、生产系统中的运行环境没有差别具备自动部署能力运维更简单监控、错误定位、安全、网络、容灾、扩容、资源管控等行为更加便捷微服务--Service微服务就是开发一个单纯的，小型的，有意义的功能作为一个单一服务。通过微服务，能够将主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。微服务的优点：App_1是一个体量小，用于实现一个特定功能或业务需求的系统可以由一个小的开发组独立完成开发松耦合，服务之间可以独立的开发和部署可以用不同的语言开发通过持续集成工具，可便捷地自动集成部署易于理解，容易修改和维护易扩展MicroServiceMicroServiceMicroService传统应用架构App_2MicroServiceMicroService微服务架构微服务--ServiceK8S中的Service是对象资源之一，一个K8SService是一系列pod的逻辑集合的抽象，同时它是访问这些pod的一个策略，有时候也被称为微服务。Service通过LabelSelector和Pod建立关联关系，并由Service决定将访问转向到后端的哪个pod。Service被创建后，系统自动创建一个同名的endpoints，该对象包含pod的ip地址和端口号集合Service分为三类：ClusterIPNodePortLoadBalancer安全—认证一个客户端访问某一个应用时，一般需要通过该应用服务端的多道安全防护，才能被服务端所接受。除了网络访问级别的（比如防火墙等）防护外，应用系统服务端一般会通过身份认证、授权以及准入控制三道措施来实现基本的安全防护。认证或身份鉴别，是指系统鉴别确认访问者身份的过程。如何保证以数字身份进行操作的操作者就是这个数字身份合法拥有者，也就是说保证操作者的物理身份与数字身份相对应，身份认证就是为了解决这个问题，作为防护网络资产的第一道关口，身份认证有着举足轻重的作用。身份认证包含如下几种方法：静态密码智能卡短信密码动态口令USBKEY生物识别K8S使用的认证方式为：客户端CA认证、HTTPBasic认证和Token认证三种方式安全—认证—BASIC认证在APIServer的启动参数中，加入--basic_auth_file参数如下：KUBE_API_ARGS=&--log-dir=/var/log/kubernetes--secure-port=443--basic_auth_file=/root/basic_auth_file“在basic_auth_file中，包含用户名、用户密码和id信息，举例如下：thomas,thomas,1admin,admin,2system,system,3使用基本认证方式从HTTP客户端访问APIServer时，HTTP请求头中的Authorization域必须包含“BasicBASE64ENCODEDUSER:PASSWORD”的值，其中”BASE64ENCODEDUSER:PASSWORD”为该访问客户base64加密算法加密后的用户名和密码。比如用户Thomas的密码为Thomas，通过下列代码访问APIServer：tmp=`base64“thomas:thomas”`curl$APISERVER/api--header&Authorization:Basic$tmp&--insecure{&versions&:[&v1&]}安全—认证—TOKEN认证Token认证方式通过添加APIServer的启动参数“--token_auth_file=SOMEFILE”实现，其中“SOMEFILE”指的是存储Token的Token文件。目前，Token认证中Token是永久有效的，而且Token列表不能被修改，除非重启APIServer。Kubernetes计划在未来的版本中，Token认证的Token将为短期有效，而且是按需要生成Token，而不是像现在存储在文件中。Token文件格式为一个包含三列的CSV格式文件，该文件的第一列为Token、第二列为用户名、第三列为用户UID。当使用Token
正在加载中，请稍后...kubernetes安全控制认证与授权(一)
kubernetes安全控制认证与授权(一)，kubernetes 对于访问 API 来说提供了两个步骤的安全措施：认证和授权。认证解决用户是谁的问题，授权解决用户能做什么的问题。通过合理的权限管理，能够保证的安全可靠。
通俗的讲，认证就是验证用户名密码，授权就是检查该用户是否拥有权限访问请求的资源。
Kubernetes集群的所有操作基本上都是通过kube-apiserver这个进行的，它提供HTTP RESTful形式的API供集群内外客户端调用。需要注意的是：认证授权过程只存在HTTPS形式的API中。也就是说，如果客户端使用HTTP连接到kube-apiserver，那么是不会进行认证授权的。所以说，可以这么设置，在集群内部组件间通信使用HTTP，集群外部就使用HTTPS，这样既增加了安全性，也不至于太复杂。
下图是 API 访问要经过的三个步骤，前面两个是认证和授权，第三个是 Admission Control，它也能在一定程度上提高安全性，不过更多是资源管理方面的作用。
下面将介绍1.6版本中已经支持的一些认证方式。
客户端证书
客户端证书认证叫作TLS双向认证，也就是服务器客户端互相验证证书的正确性，在都正确的情况下协调通信方案。
为了使用这个方案，api－server需要用－client－ca－file＝选项来开启。CA_CERTIFICATE_FILE肯定包括一个或者多个认证中心，可以被用来验证呈现给api－server的客户端证书。客户端证书的／CN将作为用户名。
静态Token文件
用token唯一标识请求者，只要apiserver存在该token，则认为认证通过，但是如果需要新增Token，则需要重启kube-apiserver组件，实际效果不是很好。
当在命令行指定- -token-auth-file=SOMEFILE选项时，API服务器从文件中读取 bearer tokens。目前，tokens持续无限期。
令牌文件是一个至少包含3列的csv文件： token, user name, user uid，后跟可选的组名。注意，如果您有多个组，则列必须是双引号，例如：
token,user,uid,&group1,group2,group3&
当通过客户端使用 bearer token 认证时，API服务器需要一个值为Bearer THETOKEN的授权头。bearer token必须是，可以放在HTTP请求头中且值不需要转码和引用的一个字符串。例如：如果bearer token是31ada4fd-adec-460c-809a-9e56ceb75269，它将会在HTTP头中按下面的方式呈现：
Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
在v1.6版本中，这个特性还是alpha特性。为了能够在新的集群中使用bootstrapping认证。Kubernetes包括一种动态管理的Bearer(持票人) token，这种token以Secrets的方式存储在kube-system命名空间中，在这个命名空间token可以被动态的管理和创建。Controller Manager有一个管理中心，如果token过期了就会删除。
创建的token证书满足[a-z0-9]{6}.[a-z0-9]{16}格式，Token的第一部分是一个Token ID，第二部分是token的秘钥。你需要在http协议头中加上类似的信息：
Authorization: Bearer 781292.db7bc3a58fc5f07e
如果要使用Bootstrap，需要在API Sever中开启--experimental-bootstrap-token-auth。同时必须在Controller Manager中开启管理中心的设置--controllers=*,tokencleaner。
在使用kubeadm部署Kubernetes时，kubeadm会自动创建默认token，可通过kubeadm token list命令查询。
静态密码文件
静态密码的方式是提前在某个文件中保存了用户名和密码的信息，然后在 apiserver 启动的时候通过参数 &basic-auth-file=SOMEFILE 指定文件的路径。apiserver 一旦启动，加载的用户名和密码信息就不会发生改变，任何对源文件的修改必须重启 apiserver 才能生效。
静态密码文件是 CSV 格式的文件，每行对应一个用户的信息，前面三列密码、用户名、用户 ID 是必须的，第四列是可选的组名（如果有多个组，必须用双引号）：
password,user,uid,&group1,group2,group3&
客户端在发送请求的时候需要在请求头部添加上 Authorization 字段，对应的值是 Basic BASE64ENCODED(USER:PASSWORD) 。apiserver 解析出客户端提供的用户名和密码，如果和文件中的某一行匹配，就认为认证成功。
这种方式很不灵活，也不安全，可以说名存实亡，不推荐使用。
Service Account Tokens 认证
有些情况下，我们希望在 pod 内部访问 apiserver，获取集群的信息，甚至对集群进行改动。针对这种情况，kubernetes 提供了一种特殊的认证方式：Service Account。 Service Account 是面向 namespace 的，每个 namespace 创建的时候，kubernetes 会自动在这个 namespace 下面创建一个默认的 Service Account；并且这个 Service Account 只能访问该 namespace 的资源。Service Account 和 pod、service、deployment 一样是 kubernetes 集群中的一种资源，用户也可以创建自己的 serviceaccount。
ServiceAccount 主要包含了三个内容：namespace、Token 和 CA。namespace 指定了 pod 所在的 namespace，CA 用于验证 apiserver 的证书，token 用作身份验证。它们都通过 mount 的方式保存在 pod 的文件系统中，其中 token 保存的路径是 /var/run/secrets/kubernetes.io/serviceaccount/token ，是 apiserver 通过私钥签发 token 的 base64 编码后的结果； CA 保存的路径是 /var/run/secrets/kubernetes.io/serviceaccount/ca.crt ，namespace 保存的路径是 /var/run/secrets/kubernetes.io/serviceaccount/namespace ，也是用 base64 编码。
如果 token 能够通过认证，那么请求的用户名将被设置为 system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT) ，而请求的组名有两个： system:serviceaccounts 和 system:serviceaccounts:(NAMESPACE)。
OpenID Connect Tokens 认证
OpenID Connect 是一些由OAuth2提供商支持的OAuth2，特别是Azure Active Directory，Salesforce和Google。OAuth2的协议的主要扩展是增加一个额外字段，返回了一个叫ID token的access token。这个token是被服务器签名的JSON Web Token (JWT) ，具有众所周知的字段，比如用户的email。
为了识别用户，验证使用来自OAuth2 token响应的id_token (而不是 access_token)作为bearer token。token如何包含在请求中可以参考下图：
使用OpenID认证，API Server需要配置
- --oidc-issuer-url，如
- --oidc-client-id，如kubernetes
- --oidc-username-claim，如sub
- --oidc-groups-claim，如groups
- --oidc-ca-file，如/etc/kubernetes/ssl/kc-ca.pem
Webhook Token 认证
Webhook Token 认证方式可以让用户使用自己的认证方式，用户只需要按照约定的请求格式和应答格式提供 HTTPS 服务，当用户把 Bearer Token 放到请求的头部，kubernetes 会把 token 发送给事先配置的地址进行认证，如果认证结果成功，则认为请求用户合法。 这种方式下有两个参数可以配置：
&authentication-token-webhook-config-file ：kubeconfig 文件说明如果访问认证服务器
&authentication-token-webhook-cache-ttl ：认证结果要缓存多久，默认是两分钟
这种方式下，自定义认证的请求和应答都有一定的格式，具体的规范请参考 官方文档的说明 。
API Server需要配置
--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-
# 为了防止头部欺骗，证书是必选项
--requestheader-client-ca-file
# 设置允许的CN列表。可选。
--requestheader-allowed-names
Keystone Password 认证
Keystone 是 openstack 提供的认证和授权组件，这个方法对于已经使用 openstack 来搭建 Iaas 平台的公司比较适用，直接使用 keystone 可以保证 Iaas 和 Caas 平台保持一致的用户体系。
需要API Server在启动时指定--experimental-keystone-url=，而https时还需要设置--experimental-keystone-ca-file=SOMEFILE。
如果请求没有通过以上任何方式的认证，正常情况下应该是直接返回 401 错误。但是 kubernetes 还提供另外一种选择，给没有通过认证的请求一个特殊的用户名 system:anonymous 和组名 system:unauthenticated 。
这样的话，可以跟下面要讲的授权结合起来，为匿名请求设置一些特殊的权限，比如只能读取当前 namespace 的 pod 信息，方便用户访问。
如果使用AlwaysAllow以外的认证模式，则匿名请求默认开启，但可用--anonymous-auth=false禁止匿名请求。}