这篇文章主要介绍“kubernetes1.5新增哪些特性”的相关知识,小编通过实际案例向大家展示操作过程,操作方法简单快捷,实用性强,希望这篇“Kubernetes1.5新增哪些特性”文章能帮助大家解决问题。Kubernetes1.5正式发
这篇文章主要介绍“kubernetes1.5新增哪些特性”的相关知识,小编通过实际案例向大家展示操作过程,操作方法简单快捷,实用性强,希望这篇“Kubernetes1.5新增哪些特性”文章能帮助大家解决问题。
Kubernetes1.5正式发布修复了很多已知问题,进一步增强federation相关特性、将PetSet改名为StatefulSet、将ScheduledJobs改名为CronJobs、新增了命令kubectl,用于操作federation等。
在Kubernetes1.5中,对于kubelet新增加了几个同认证/授权相关的几个启动参数,分别是:
认证相关参数:
anonymous-auth参数:是否启用匿名访问,可以选择true或者false,默认是true,表示启用匿名访问。authentication-token-WEBhook参数:使用tokenreviewapi来进行令牌认证。authentication-token-webhook-cache-ttl参数:webhook令牌认证缓存响应时长。client-ca-file参数:表示使用x509证书认证,如果设置此参数,那么就查找client-ca-file参数设置的认证文件,任何请求只有在认证文件中存在的对应的认证,那么才可以正常访问。
授权相关参数:
authorization-mode参数:kubelet的授权模式,可以选择AlwaysAllow或者Webhook,如果设置成Webhook,那么使用SubjectAccessReviewAPI进行授权。authorization-webhook-cache-authorized-ttl参数:webhook授权时,已经被授权内容的缓存时长。authorization-webhook-cache-unauthorized-ttl参数:webhook授权时,没有被授权内容的缓存时长。
默认anonymous-auth参数设置成true,也就是可以进行匿名认证,这时对kubelet API的请求都以匿名方式进行,系统会使用默认匿名用户和默认用户组来进行访问,默认用户名“system:anonymous”,默认用户组名“system:unauthenticated”。
可以禁止匿名请求,这时就需要设置kubelet启动参数:“–anonymous-auth=false”,这时如果请求时未经过认证的,那么会返回“401 Unauthorized”。
可以使用x509证书认证(X.509格式的证书是最通用的一种签名证书格式)。这时就需要设置kubelet启动参数:“–client-ca-file”,提供认证文件,通过认证文件来进行认证。同时还需要设置api server组件启动参数:“–kubelet-client-certificate”和“–kubelet-client-key”。在认证文件中一个用户可以属于多个用户组,比如下面例子产生的认证:
openssl req -new -key jbeda.pem -outjbeda-csr.pem -subj “/CN=jbeda/O=app1/O=app2”
这个例子创建了csr认证文件,这个csr认证文件作用于用户jbeda,这个用户属于两个用户组,分别是app1和app2。
可以启用令牌认证,这时需要通过命令“–runtime-config=authentication.k8s.io/v1beta1=true“启用api server组件authentication.k8s.io/v1beta1相关的API,还需要启用kubelet组件的“–authentication-token-webhook”、“–kubeconfig”、“–require-kubeconfig”三个参数。
kubeconfig参数:设置kubelet配置文件路径,这个配置文件用来告诉kubelet组件api server组件的位置,默认路径是。
require-kubeconfig参数:这是一个布尔类型参数,可以设置成true或者false,如果设置成true,那么表示启用kubeconfig参数,从kubeconfig参数设置的配置文件中查找api server组件,如果设置成false,那么表示使用kubelet另外一个参数“api-servers”来查找api server组件位置。
在kubernetes源代码中,有一个错误的注释:
func NewKubeletServer() *KubeletServer {versioned:= &v1alpha1.KubeletConfiguration{}api.Scheme.Default(versioned)config:= componentconfig.KubeletConfiguration{}api.Scheme.Convert(versioned,&config, nil)return&KubeletServer{KubeConfig: flag.NewStringFlag(“/var/lib/kubelet/kubeconfig”),RequireKubeConfig: false, // in 1.5, default to trueKubeletConfiguration:config,}}
这里面对RequireKubeConfig参数默认值的设置是false,但是在注释中写的确实true。
启用令牌认证后,kubelet会调用TokenReview API来进行令牌认证。
下面是一个kubeconfig文件格式样例:
clusters:-name: name-of-remote-authn-servicecluster:certificate-authority: /path/to/ca.pem # 校验远程服务的认证文件server: https://authn.example.com/authenticate # 远程服务访问Https路径users:-name: name-of-api-serveruser:client-certificate: /path/to/cert.pem # webhook插件使用的认证文件client-key: /path/to/key.pem # 认证文件对应的密钥文件current-context: webhookcontexts:– context:cluster: name-of-remote-authn-serviceuser: name-of-api-severname: webhook
认证请求格式样例如下:
{“apiVersion”: “authentication.k8s.io/v1beta1”,“kind”: “TokenReview”,“spec”: {“token”: “(BEARERTOKEN)”}}
成功的认证响应如下:
{“apiVersion”: “authentication.k8s.io/v1beta1”,“kind”: “TokenReview”,“status”: {“authenticated”: true,“user”: {“username”: “janedoe@example.com”,“uid”: “42”,“groups”: [“developers”,“qa”],“extra”: {“extrafield1”: [“extravalue1”,“extravalue2”]}}}}
失败的认证响应如下:
{“apiVersion”: “authentication.k8s.io/v1beta1”,“kind”: “TokenReview”,“status”: {“authenticated”: false}}
任何请求被成功认证后才会被授权,包括匿名认证请求。默认的授权模式是AlwaysAllow,意味着允许任何请求。其实对于API的请求是需要进行更细粒度划分和授权的,有下面两点原因:
虽然允许匿名用户请求,但是应该限制匿名用户可以访问的API。
虽然允许认证用户请求,但是不同认证用户应该可以访问不同的API,而不能所有认证用户只能访问相同的API。
要想进行API权限控制,需要通过命令“–runtime-config= authorization.k8s.io /v1beta1=true“启用api server组件authorization.k8s.io/v1beta1相关的API,还需要将授权模式参数“–authorization-mode”设置成Webhook,然后启用kubelet组件的“–kubeconfig”和“–require-kubeconfig”两个参数,这两个参数的作用在上面认证章节已经详细介绍过了,这里不再介绍。
Kubelet接着就会调用api server组件的SubjectAccessReviewAPI来判断哪个请求需要进行授权控制。
请求动作类型是根据HTTP访问类型进行划分的,如下面表格所示:
HTTP verb request verbPOST createGET, HEAD getPUT updatePATCH patchDELETE delete
资源访问请求是根据不同请求路径来进行划分的,如下面表格所示:
Kubelet API 资源名称 子资源名称/stats/* nodes stats/metrics/* nodes metrics/logs/* nodes log/spec/* nodes specall others nodes proxy
对于资源访问请求,访问时名字空间和API组这两个属性永远都是空值,资源名称的属性值就是kubelet所在节点对象名称。
要是想让kubelete API可以进行权限控制,还需要确保api server组件已经启用了“–kubelet-client-certificate”和“–kubelet-client-key”连个参数,
kubelet-client-certificate参数:客户端认证文件路径
kubelet-client-key参数:客户端密钥文件路径
还确保客户端被授权可以访问下面属性:
verb=*, resource=nodes,subresource=proxyverb=*, resource=nodes, subresource=statsverb=*, resource=nodes,subresource=logverb=*, resource=nodes,subresource=specverb=*, resource=nodes,subresource=metrics
关于“Kubernetes1.5新增哪些特性”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识,可以关注编程网精选频道,小编每天都会为大家更新不同的知识点。
--结束END--
本文标题: Kubernetes1.5新增哪些特性
本文链接: https://lsjlt.com/news/315771.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
2024-05-24
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0