📋
k8s use handbook
  • 概述
  • 1. kuberbetes应用接入准则篇
    • 1.1 git分支管理规范
    • 1.2 接入elk字段格式以及约定
    • 1.3 健康检测接口规范
    • 1.4 项目命名规范
  • 2. kubernetes集群部署篇
    • 2.0 kubernetes手动安装概览
      • 201 创建跟证书和秘钥
      • 202 ETCD集群部署及维护
      • 203 kubectl部署以及基本使用
      • 204 Master节点部署及维护
        • 2041 kube-apiserver
        • 2042 kube-scheduler
        • 2043 kube-controller-manager
      • 205 Node节点部署及维护
        • 2051 Flannel部署及维护
        • 2052 kubernetes runtime部署及维护
        • 2053 kubelet
        • 2054 kube-proxy
    • 2.1 kubernetes ansible安装
    • 2.2 kubernetes kubeadm安装
    • 2.3 kubernetes 组件安装
      • 231 coredns
      • 232 kube-dashboard
  • 3. kubernetes权限控制篇
    • 认证
    • 授权
    • 准入机制
  • 4. what happens when k8s .....
    • Kubernetes使用什么方法方法来检查应用程序的运行状况?
    • 如何优雅的关闭pod?
    • TLS bootstrapping 是如何工作的?
    • 怎么编辑kubernetes的yaml文件以及kubernetes的控制是什么样的?
    • deployment如何使用不同的策略部署我们的程序?
    • Kubernetes 如何接收请求,又是如何将结果返回至客户端的?
    • Kubernetes 的调度流程是怎样的?
    • Kubelet 是如何接受调度请求并启动容器的?
    • Kube-proxy 的作用,提供的能力是什么?
    • Kubernetes 控制器是如何工作的?
    • ingress-service-deployment如何关联的?
    • 如何指定pod的运行节点?
    • Https 的通信过程?
  • 5. kubernetes私有仓库篇
  • 6. kubernetes CI/CD篇
    • 5. kubernetes cicd发布流水线
  • 6. kubernetes日志系统篇
    • 6.1 elk使用规范和指南
    • 6.2 kibana搜索简易指南
    • 6.3 基于es api进行查询的注意事项
    • 6.4 集群部署
      • 6.4.1 es规划
        • 索引的生命周期
      • 6.4.2 安装
      • 6.4.3 elasticsearch配置
      • 6.4.4 logstash配置
      • 6.4.5 kibana配置
      • 6.4.6 enable-xpack
        • 6.4.6.1 X-Pack on Elasticsearch
        • 6.4.6.2 X-Pack on Logstash
        • 6.4.6.3 X-Pack on Kibana
        • 6.4.6.4 xpack破解
        • 6.4.6.5 LDAP user authentication
      • 6.4.7 Cerebro configuration
      • 6.4.8 Curator configuration
    • 6.10 备份恢复
  • 7.0 kuberbetes服务暴露Ingress篇
    • 7.1 Ingress规划
    • 7.2 Traefik ingress controller
      • 7.2.1 Traefik配置详解
      • 7.2.2 Traefik部署
      • 7.2.3 分场景使用示例
      • 7.2.4 Traefik功能示例
      • 7.2.5 Traefik日志收集
      • 7.2.6 https证书更新
    • 7.3 Nginx ingress controller
      • 7.3.1 Nginx 配置详解
      • 7.3.2 Nginx 部署
      • 7.3.3 使用示例
    • 7.4 ingress日常运维
  • 8.0 kubernetes监控篇
    • 8.1 prometheus非k8s部署
    • 8.2 prometheusk8s部署
    • 8.3 prometheus 配置文件详解
    • 8.3 prometheus alertmanager
  • 9.0 kubernetes配置管理篇
  • 10.0 权威DNS篇
    • 10.1 PowerDNS安装部署
    • 10.1 PowerDNS zone设置
由 GitBook 提供支持
在本页

这有帮助吗?

  1. 1. kuberbetes应用接入准则篇

1.4 项目命名规范

上一页1.3 健康检测接口规范下一页2. kubernetes集群部署篇

最后更新于5年前

这有帮助吗?

“There are only two hard problems in Computer Science: cache invalidation and naming things.” ——Phil Karlton

命名是一项艰难而重要的任务,在Quora上也是,按照如下的一些基本规则来进行命名,会帮助团队建设清晰而又精炼的项目结构:

  • 基础命名法则:

    • 基础的命名方式参考 github 和 gitlab 的多数项目,适用小写+中划线命名法(lowercase and dashes pattern)。 eg: 项目命名为 project-name ,很显然你要同步的git地址也会是 http://the.git.address/group-name/project-name.git;

  • 项目仓库(repository)通用命名法则:

    • 所有项目(repository)应根据自己提供的功能进行可以理解的清晰的描述,除非必要,一般使用名词单数。 eg:使用 purchase-rest-service 而不使用 rest-service 的描述;

    • 尽可能的避免使用大家不能理解的缩写、简写等。eg:不要使用xxx-pom-xxx之类的神秘词语进行描述;

    • 所有的的项目(repository)在建立仓库时,需要带上相应产品线名称的前缀。eg: 商业平台的广告投放命名为 biz-demand-side-service;

  • 微服务项目仓库(repository)的命名法则:

    • 关于微服务的项目命名应以-service 为后缀,来声明一个服务,不要以-server 或者 -platform或者 -api 这样宽泛的名词来进行描述。eg:内容管理的服务以 content-mangement-service 描述;

  • 客户端项目仓库(repository)的命名法则:

    • 不同源的客户端统一以 -client 为后缀描述,由于平台的不同,可以通过叠加 -client-{platform} 来完善描述。 eg:Web端以 -client-web描述;,同样根据项目的颗粒度,更详尽的描述如 -client-wechat 、 -client-mobile 、 -client-ios-ipad也在允许范围之列。

  • 工具脚本类项目仓库(repository)的命名法则:

    • 有些工具类的项目(repository)可能会根据其类型,在命名中通过 -plugin 、 -toolkit 或者 -script 后缀显示,这类项目以 的居多。同样其用途或者适用场景可以在明明最后叠加 -{usage} 。 eg: jira打包工具 publish-toolkit-for-jira;

  • 完整项目仓库(repository)的命名法则:

    • 有些项目因为其规模不大,其仓库包括前后端甚至一些脚本工具,适用与直接描述系统或者业务名称,这里有很多很好的,可以直接使用项目名称如 biz-intelligence 或者 oss-data-manager ;

  • 其它注意事项或者案例(待完善):

    • 一些案例的命名:-sample-{usage}/{platform};

    • 一些开发工具包的命名:-sdk-{usage}/{platform};

经久不衰的好问题
案例
业务产品线相关
测试运维相关