首页 文章 精选 留言 我的

精选列表

搜索[优化],共10000篇文章
优秀的个人博客,低调大师

详细讲解如何对K8S权限进行优化

背景 一直以来在内网开发、测试环境的K8S web控制台使用的是rancher面板。 通过使用rancher面板服务,在容器管理上运维、开发、测试人员的工作效率得到了极大的提升 问题 由于早期仅注重功能实现及用户体验上问题,忽略了权限管理上的问题。给用户开放出去的rancher面板用户均为cluster-owner权限。导致最近一天,突然接到研发人员的通知,说开发环境namespace下的所有工作负载都消失了。通过排查,发现问题时刻所有的node节点都正常运行,dev namespace已不存在,另外两个 test1、test2namespace下的全部资源均运行正常。 因此初步怀疑是人工方式对namespace进行了删除操作,将dev namespace下的全部资源删除(包括secret、sa、configmap、pvc、deployment、svc等) 用户可能通过rancer面板删除namespace,也有少部分研发人员有服务器权限,可以操作kubectl工具进行删除操作,因此需要对rancher和kubectl工具进行权限配置 解决方案 1、首先对环境进行恢复 2、对rancher面板的权限配置 3、对kubect客户端进行权限配置 Rancher权限配置 当前rancher的用户均为全部类型的本地用户,在授权上将本地用户授权给集群 创建集群的用户角色Developer 对新创建的角色进行授权,新的角色需要继承cluster member和view all projects角色的权限 在集群中进行授权 kubectl权限配置 创建serviceaccount kubectlcreatesadeveloper 置developer-role的相关权限 cat<<EOF|kubectlapply-f- apiVersion:rbac.authorization.k8s.io/v1 kind:ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate:"true" labels: kubernetes.io/bootstrapping:rbac-defaults name:developer-role namespace:default rules: -apiGroups: -"" resources: -pods -configmaps verbs: -get -list -watch -apiGroups: -apps resources: -pods -deployments verbs: -get -list -watch -create -update EOF 通过配置ClusterRoleBinding绑定serviceaccount和ClusterRole cat<<EOF|kubectlapply-f- apiVersion:rbac.authorization.k8s.io/v1 kind:ClusterRoleBinding metadata: name:developer-role-binding namespace:default roleRef: apiGroup:rbac.authorization.k8s.io kind:ClusterRole name:developer-role subjects: -kind:ServiceAccount name:developer namespace:default EOF 将密钥中的ca.crt解码后导出 kubectlgetsecretdeveloper-token-2rz7l-ndefault-oyaml|grepca.crt:|awk'{print$2}'|base64-d>/home/ca.crt 生成config文件 kubectlconfigset-clusterfjhb-lan-k8s--server=https://192.168.1.59:9443--certificate-authority=/home/ca.crt--embed-certs=true--kubeconfig=/home/test.config 将developer sa的token更新到config文件中 kubectlconfigset-clusterfjhb-lan-k8s--server=https://192.168.1.59:9443--certificate-authority=/home/ca.crt--embed-certs=true--kubectoken=$(kubectldescribesecretdeveloper-token-2rz7l-ndefault|awk'/token:/{print$2}') kubectlconfigset-credentialsdeveloper--token=$token--kubeconfig=/home/test.config 配置集群认证访问的上下文信息 kubectlconfigset-contextdeveloper--cluster=fjhb-lan-k8s--user=developer--kubeconfig=/home/test.config kubectlconfiguse-contextdeveloper--kubeconfig=/home/test.config 测试与验证 kubectlgetcm-ndefault--kubeconfig=/home/test.config kubectlgetcm-ntest1--kubeconfig=/home/test.config kubectldeletecmingress-controller-leader-nginx-ndefault--kubeconfig=/home/test.config 后续将test.config复制到kubectl客户端所在的主机上,放在运行命令用户的~/.kube目录下,重命名为config,即可达到预期效果!

优秀的个人博客,低调大师

网易开源服务网格组件 Slime:优化 Istio 高阶功能

近日,网易数帆旗下轻舟微服务团队开源了一个服务网格组件 Slime,可以作为 Istio 的 CRD 管理器,旨在通过更为简单的配置实现 Istio/Envoy 的高阶功能。 据项目官方介绍,推出 Slime 项目是为了弥补服务网格 Istio 在面对本地限流、黑白名单、降级等微服务治理的高阶功能时的不足。 作为当前主流的云原生服务网格项目,Istio 有着一套行之有效的上层抽象,通过配置 VirtualService,DestinationRule 等 CR 可以实现版本分流、灰度发布、负载均衡等功能,但是在面对本地限流、黑白名单、降级等微服务治理的高阶功能时,这套抽象显得力有不逮。 起初 Istio 给出的解决方案是 Mixer,将这些原本属于数据面的功能上升到 Mixer Adapter 中,虽然解决了功能扩展的问题,但其集中式的架构遭到了不少关注者对其性能的质疑。最终,Istio 在新版本中自断其臂,弃用了 Mixer,这就使得高阶功能的扩展成为目前版本的一块空白。 另一方面,Istio 配置是全量推送的,这就意味着在大规模的网格场景下需推送海量配置,为了减少推送配置量,用户不得不事先搞清楚服务间的依赖关系,配置 SidecarScope 做配置隔离,而这无疑增加了运维人员的心智负担,易用性和性能成为不可兼得的鱼和熊掌。 针对 Istio 目前的一些弊端,网易团队开启了 Slime 项目。该项目是基于 k8s-operator 实现的,作为 Istio 的 CRD 管理器,可以无缝对接 Istio,无需任何的定制化改造。Slime 内部采用了模块化的架构,目前包含了三个非常实用的子模块: 配置懒加载:无须手动配置 SidecarScope,按需加载配置信息和服务发现信息,解决了全量推送的问题。 Http 插件管理:使用新的 CRD pluginmanager/envoyplugin 包装了可读性,可维护性较差的 envoyfilter,使得插件扩展更为便捷。 自适应限流:可结合监控信息自动调整限流策略,填补了 Istio 限流功能的短板。 Slime 的源码目前已经开放,团队表示项目仍处于早期阶段,希望有更多的 mesher 加入社区或为项目提出建议,帮助完善它。团队后续还会开放更多实用功能在 Slime 中。

资源下载

更多资源
优质分享App

优质分享App

近一个月的开发和优化,本站点的第一个app全新上线。该app采用极致压缩,本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册