职场学习总结1:go与k8s基础个人总结

52 阅读9分钟

入职三月工作总结

工作三个月了,做一个基础的总结,这段时间干了些啥,然后有什么学的到的东西,记录一下

一、go的基础知识

1.go命令

go build    # 编译指定文件或者代码包
go install  #还会把导入的依赖包编译到 $GOPATH/pkg,并缓存,如果包未做更改,下次编译则直接使用缓存。 go build 命令加参数 -i 也能达到go install 的效果。
go get      #命令用于动态获取远程代码包及其依赖包,并进行编译和安装。
go mod init (my-module-name)
go clean    #命令用于删除执行其他命令时产生的文件或目录
go list     #会列出当前安装的包
# 编译命令
CGO_ENABLED=0  GOOS=linux  GOARCH=amd64  go build main.go

详情:zhuanlan.zhihu.com/p/161494871

2.go指针

var a int= 20   /* 声明实际变量 */
var ip *int        /* 声明指针变量 */
ip = &a  /* 指针变量的存储地址 */
var value = *ip /* 指针指向的值 */
// &取值,*取地址

在go中其实并不存在引用传递,slice,map,channel,interface,func这些本质上都是值传递,只是我们理解成引用传递,是因为创建的时候保存的是他们的指针地址。

详情:juejin.cn/post/722173…

3.go的类型转换

// 将整型转换为浮点型
var a int = 10
var b float64 = float64(a)

// 将一个字符串转换成另一个类型
var str string = "10"
var num int
// 转换成整数
num, _ = strconv.Atoi(str)
// 转换成float
num, err := strconv.ParseFloat(str, 64)
// 浮点转换到字符
num := 3.14
str := strconv.FormatFloat(num, 'f', 2, 64)
fmt.Printf("浮点数 %f 转为字符串为:'%s'\n", num, str)

4.go的接口类型转换

接口类型转换有两种情况:类型断言和类型转换。 类型断言用于将接口类型转换为指定类型,其语法为:

var i interface{} = "Hello, World"
str, ok := i.(string)
if ok {
    fmt.Printf("'%s' is a string\n", str)
} else {
    fmt.Println("conversion failed")
}

5.go的并发处理和通道

goroutine 是轻量级线程,goroutine 的调度是由 Golang 运行时进行管理的。 通道(channel)是用来传递数据的一个数据结构。

ch := make(chan int)
ch <- v    // 把 v 发送到通道 ch
v := <-ch  // 从 ch 接收数据并把值赋给 v

通道缓冲区,通道可以设置缓冲区,通过 make 的第二个参数指定缓冲区大小:

ch := make(chan int, 100)

带缓冲区的通道允许发送端的数据发送和接收端的数据获取处于异步状态,就是说发送端发送的数据可以放在缓冲区里面,可以等待接收端去获取数据,而不是立刻需要接收端去获取数据。 不过由于缓冲区的大小是有限的,所以还是必须有接收端来接收数据的,否则缓冲区一满,数据发送端就无法再发送数据了。 注意:如果通道不带缓冲,发送方会阻塞直到接收方从通道中接收了值。如果通道带缓冲,发送方则会阻塞直到发送的值被拷贝到缓冲区内;如果缓冲区已满,则意味着需要等待直到某个接收方获取到一个值。接收方在有值可以接收之前会一直阻塞。

详情:juejin.cn/post/728791…

二、K8S的基础知识

1.资源

1.1 基本资源:

Pods:Pod 是 Kubernetes 中最小的可部署单位,它包含一个或多个容器,并共享相同的网络命名空间和存储卷。 Service:Service 定义了一组 Pod 的网络访问方式,可以提供负载均衡、服务发现和稳定的网络端点。 Volume:Volume 用于在 Pod 中存储数据,可以是持久性存储或临时存储。

1.2 控制器资源:

ReplicaSet:ReplicaSet 用于定义一组 Pod 的副本数量,以确保它们按照所期望的数量运行。 Deployment:Deployment 提供了对应用程序的声明式定义,允许滚动升级、回滚和伸缩应用程序。 StatefulSet:StatefulSet 用于管理有状态应用程序,它为每个 Pod 提供稳定的标识和有序部署。 DaemonSet:DaemonSet 用于确保集群中的每个节点运行相同数量的 Pod,通常用于日志收集和监控任务。

1.3 配置和存储资源:

ConfigMap:ConfigMap 允许将配置数据以键值对的形式注入到容器中,以配置应用程序。 Secret:Secret 用于存储敏感信息,如密码、令牌等。 PersistentVolume:PersistentVolume 定义了集群中的存储资源,可以由 Pod 使用。 PersistentVolumeClaim:PersistentVolumeClaim 用于请求 PersistentVolume 以供 Pod 使用。

1.4 安全和身份验证资源:

ServiceAccount:ServiceAccount 用于确定 Pod 的身份和访问权限。 Role 和 ClusterRole:Role 和 ClusterRole 用于定义 RBAC 规则,以确定用户或服务账户的权限。 RoleBinding 和 ClusterRoleBinding:RoleBinding 和 ClusterRoleBinding 用于将 Role 和 ClusterRole 与用户或服务账户绑定。

1.5 网络和服务资源:

NetworkPolicy:NetworkPolicy 用于定义 Pod 之间的网络策略,包括入站和出站流量的规则。 Ingress:Ingress 定义了 HTTP 和 HTTPS 服务的外部访问规则。 ServiceMonitor:ServiceMonitor 用于定义监控规则,以便 Prometheus 等监控系统监视服务。

1.6 自定义资源:

Custom Resource Definitions (CRDs):CRDs 允许用户定义自定义资源类型,以扩展 Kubernetes 平台来支持特定的应用程序或服务。

1.7 扩展资源

CronJobs:Kind 为 "CronJob",用于在预定的时间间隔执行任务。 Jobs:Kind 为 "Job",用于管理一次性任务。

上述的所有资源都是一个单独的kind,他们有不同的apiVersion。

2.分组apiVersion

在 Kubernetes 中,apiVersion 用于指定资源对象所属的 API 组和版本。以下是一些常见的 apiVersion 示例,代表不同的 API 组和版本:

2.1 核心 API 组(Core API Group):

apiVersion: v1:代表核心 API 组的版本,通常用于核心资源对象如 Pod、Service 等。

2.2 扩展 API 组(Extensions API Group):

apiVersion: extensions/v1beta1:代表扩展 API 组的版本,用于资源对象如 DaemonSet、ReplicaSet、Ingress 等。

2.3 批处理 API 组(Batch API Group):

apiVersion: batch/v1:代表批处理 API 组的版本,用于资源对象如 Job、CronJob 等。

2.4 网络 API 组(Networking API Group):

apiVersion: networking.k8s.io/v1:代表网络 API 组的版本,用于资源对象如 NetworkPolicy、Ingress 等。

2.5 存储 API 组(Storage API Group):

apiVersion: storage.k8s.io/v1:代表存储 API 组的版本,用于资源对象如 PersistentVolume、PersistentVolumeClaim 等。

2.6 认证和授权 API 组(Authentication and Authorization API Group):

apiVersion: rbac.authorization.k8s.io/v1:代表认证和授权 API 组的版本,用于资源对象如 Role、RoleBinding、ClusterRole、ClusterRoleBinding 等。

2.7 自定义资源定义 API 组(Custom Resource Definitions, CRDs):

apiVersion: custom.api.group/v1:代表自定义资源定义的 API 组和版本,自定义资源定义的 API 组和版本根据其定义而定。

3.资源模板

apiVersion: <API版本>
kind: <资源对象类型>
metadata:
  name: <资源对象名称>
  labels:
    <标签键1>: <标签值1>
    <标签键2>: <标签值2>
spec:
  <资源对象的配置属性1>: <配置值1>
  <资源对象的配置属性2>: <配置值2>
  # 可以根据需要添加更多配置属性

不同的资源有不同的配置属性。根据资源对象类型进行分类:

3.1 Pod 配置属性:

containers:包含一个或多个容器的列表,每个容器有自己的配置属性。 volumes:定义 Pod 中的存储卷。 restartPolicy:定义 Pod 中容器的重启策略。

3.2 Service 配置属性:

selector:指定要与服务关联的 Pod 的标签选择器。 ports:定义服务公开的端口和协议。 type:指定服务的类型,如 ClusterIP、NodePort、LoadBalancer。

3.3 Deployment 配置属性:

replicas:定义副本数量。 strategy:定义升级策略,如 RollingUpdate 策略。 template:定义要部署的 Pod 模板。

3.4 ConfigMap和Secret 配置属性:

data:定义配置数据,可以是键值对的形式。 binaryData:定义二进制数据,如证书等。

3.5 PersistentVolume和PersistentVolumeClaim 配置属性:

capacity:定义存储容量。 accessModes:定义存储访问模式。 storageClassName:定义存储类名称。

3.6 Ingress 配置属性:

rules:定义路由规则。 tls:定义TLS证书配置。

3.7 CronJob和Job 配置属性:

schedule:定义任务执行的计划。 completions:定义任务完成的数量。 parallelism:定义并行执行的任务数量。

例如一个deployment的yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app-deployment
spec:
  replicas: 3  # 指定副本数量
  selector:
    matchLabels:
      app: my-web-app
  template:
    metadata:
      labels:
        app: my-web-app
    spec:
      affinity:
        nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
                - key: key1  # 节点标签的键
                operator: NotIn  # 反亲和性运算符
                values:
                - value1  # 不希望 Pod 被调度到具有 key1=value1 的节点
      containers:
      - name: my-web-app-container
        image: nginx:latest  # 使用 Nginx 镜像作为容器
        ports:
        - containerPort: 80  # 暴露容器的端口
  • apiVersion 和 kind 指定了资源对象的类型,这里是一个 Deployment。
  • metadata 部分定义了 Deployment 的名称。
  • spec 部分包含了 Deployment 的配置信息:
    • affinity 部分定义了节点亲和性的配置。
    • replicas 指定了要创建的 Pod 的副本数量(这里是 3 个副本)。
    • selector 部分定义了用于选择要管理的 Pod 的标签选择器。
    • template 部分定义了要创建的 Pod 的模板,包括标签和容器的配置:
    • metadata 部分定义了 Pod 的标签。
    • spec 部分定义了 Pod 中的容器,这里使用了 Nginx 镜像,并将容器的端口暴露为 80。

4.命令工具

上班主要用的是openshift,所以命令就用oc来代替kubectl。

oc get co/node # 获得clusteroperator的信息,可以看到底座的版本,或者获得node的信息
oc get all # 获得所有资源
oc -n <namespace> get <sourece> <soucreename> -o yaml/json 
# 获得namespace下的资源,使用yaml或者json的格式,可以是statefulset,deployment,service,pod等
oc apply -f <path.yaml> # 创建资源
oc -n <namespace> describe  <sourece> <soucreename> # 查看资源,出错的时候常用这个来检测错误
oc -n <namespace> get svc -o yaml/json # 获得namespace下的service
oc -n <namespace> logs <podname> # 查看pod的日志,-f是一直打印,-p是打印上一次的日志,用于看上一次的错误发生
oc -n <namespace> delete <sourece> <soucreename> # 删除pod
oc -n <namespace> edit <sourece> <soucreename> # 编辑资源

主要用到的就这些,其实还有很多学过的,但是没怎么用,先写这么多吧。

基础的就这些,主力的生产其实用的是operator-service这一套操作,另起一篇再写。