容器传参

构建一个测试镜像

FROM ubuntu
CMD ["sleep"，"5"]

运行这个容器发现睡眠了5秒以后退出，如果我们希望自己指定可以直接在docker后面加命令覆盖，写法如下

docker run sleeper sleep 10

上面的过程显得有些不合理，我们希望只传入参数，所以ENTRYPOINT出现了

FROM ubuntu
ENTRYPOINT ["sleep"]
#如果没有传参就会拼接这个到后面 如果传入了参数就会拼接我们传入的参数
CMD ["5"]

docker run sleeper #休眠5秒
docker run sleeper 10 #休眠10秒 覆盖 CMD ["5"] 并拼接在后面 也就是最后执行的是 sleep 10

Pod 传参

apiVersion: v1
kind: Pod
metadata:
  name: sleeper
spec:
  containers:
  - name: sleeper
    image: s09g/sleeper
    command: ["sleep"]
    args: ["10"]

pod文件使用command字段覆盖了入口点ENTRYPOINT指令，args字段覆盖了docker文件中的命令CMD指令。
不是command字段覆盖了docker文件中的cmd指令
生产环境中我们是不这样使用的，我们往往使用环境变量进行传参

环境变量

1 通过定义Env

apiVersion: v1
kind: Pod
metadata:
  name: ngix-demo
  labels:
    type: nginxservice
spec:
  containers:
  - name: ginxservice
    image: nginx
    env:
    - name: DEMO_GREETING
      value: "Hello from the environment"
    - name: DEMO_FAREWELL
      value: "Such a sweet sorrow"

当有Pod文件时，管理存储在文件中的环境数据会很复杂。除了使用plain text键值对格式指定环境变量的直接方法，还有使用ConfigMap和Secrets等方法来管理环境变量更加的方便。
2 使用ConfigMap
1)使用命令的方式
g给这个pod创建一个configmap 并且指定了两个键值

kubectl create configmap web-config --from-literal=UI_COLOR=red --from-literal=APP_MODE=prod

2)使用yml

• 创建configMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: web-config
data:
  UI_COLOR: red
  APP_MODE: prod

#查看configMap
kubectl create -f config-map.yaml

kubectl get configmaps

kubectl describe configmaps

• 配置pod

apiVersion: v1
kind: Pod
metadata:
  name: sample-webapp
labels:
  name: sample-webapp
spec:
  containers:
  - name: sample-webapp
    image: sample-webapp
    ports:
    - containerPort: 8080
    envFrom: #可以传入多个 每一个对应一个configMap
    - configMapRef:
        name: web-config

上面这个yml是整体配置，也可以指定单个值

apiVersion: v1
kind: Pod
metadata:
  name: sample-webapp
labels:
  name: sample-webapp
spec:
  containers:
  - name: sample-webapp
    image: sample-webapp
    ports:
    - containerPort: 8080
    env:
	- name: UI_COLOR
	  valueFrom:
	    configMapKeyRef:
	      name: web-config
	      key: UI_COLOR

还可以通过数据卷的方式进行注入

apiVersion: v1
kind: Pod
metadata:
  name: sample-webapp
labels:
  name: sample-webapp
spec:
  volumes:
  - name: web-config-volume
    configMap:
      name: web-config
  containers:
  - name: sample-webapp
    image: sample-webapp
    ports:
    - containerPort: 8080
    envFrom:
    - configMapRef:
        name: web-config

Secrets

ConfigMap以纯文本格式存储配置数据。如果需要通过用户名和密码连接数据库，虽然可以将主机名和用户名移到ConfigMap中，但ConfigMap不是存储密码的正确位置。和configMap的用法一样
1 命令的方式

kubectl create secret generic web-secret --from-literal=DB_User=root --from-literal=DB_Password=passwd #可以使用名文 命令行会自动编码

这里也可以使用--from-file指定文件路径文件路径存储用户名和密码

kubectl create secret generic db-user-pass \
  --from-file=username=./username.txt \
  --from-file=password=./password.txt

2 使用yml

apiVersion: v1
kind: Secret
metadata:
  name: webapp-secret
data:
  DB_User: cm9vdA==
  DB_Password: cGFzc3dk

#获取编码
echo -n "passwd" | base64 #可以得到编码以后的值
#创建secret
kubectl create –f secret-data.yaml
#获取secret
kubectl get secrets
kubectl describe secrets
#可以查看虽然是base64编码的但是也相当于是名文
kubectl get secret webapp-secret –o yaml
#我们可以进行解码 所以我们要注意不能向外透露这个 yaml文件
echo –n ‘cm9vdA==’ | base64 --decode

整个引入

apiVersion: v1
kind: Pod
metadata:
  name: sample-webapp
labels:
  name: sample-webapp
spec:
  containers:
  - name: sample-webapp
    image: sample-webapp
    ports:
    - containerPort: 8080
    envFrom:
    - secretRef:
        name: webapp-secret

也可以单独引用

env:
- name: DB_Password
  valueFrom:
    secretKeyRef:
      name: webapp-secret
      key: DB_Password

同样支持数据卷

volumes:
- name: webapp-secret-volume
  secret:
    secretName: webapp-secret

注意这个时候webapp-secret-volumes是两个文件,比如创建下面来两个文件

echo "my_psql_user" >> psql_user.txt
#创建一个用户
docker secret create psql_user psql_user.txt
#查看现在有的密匙
docker secret ls
#创建一个密码的密匙 这是另一种方式
echo "myDBpassWORD" | docker secret create psql_pass - #- 表示从终端输入的

Job

Job是为了解决如批处理、生成报告和发送电子邮件, 执行特定任务,然后完成｡这些工作负载的生存期很短,执行一组任务, 然后退出｡这样短时间运行任务，一般作为离线业务。离线业务的特点是必定会退出，不会无期限地运行下去，所以它的调度策略与在线业务存在很大的不同，需要考虑运行超时、状态检查、失败重试、获取计算结果等管理事项。
基础指令

#获取所有的job
kubectl get jobs
#查看JOB
kubectl get job error-job 
#查看日志
kubectl logs expr-job-kblhb 
#删除Job
kubectl delete job expr-job

1 离线任务，运行完直接退出

apiVersion: v1
kind: Pod
metadata:
  name: expr
spec:
  restartPolicy: Never #注意这个需要指定否则k8s会不停的拉起这个容器
  containers:
  - name: expr
    image: ubuntu
    command: ['expr', '3', '+', '2'] 

Kubernetes希望应用程序永远存在｡pod的默认行为是尝试重新启动容器以使其保持运行｡ Pod上有个重新启动策略restartPolicy，默认情况下设置为Always｡所以pod总是退出后重新创建｡这就是restartPolicy: Never的原因。 我们可以将这个属性设定为Never或OnFailure,来覆写这个行为｡这样, Kubernetes在Job完成后不会重新启动容器｡
2 定时任务

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: '*/1 * * * *'
  jobTemplate: #指定Job模板
    spec:
      template: #指定Jobpod模板
        spec:
          restartPolicy: Never
          containers:
          - image: busybox
            name: hello
            command: ["/bin/echo"]
            args: ["hello", "world"]

#查看任务
kubectl get cj

3 批处理

apiVersion: batch/v1
kind: Job
metadata:
  name: error-job
spec:
  completions: 3 #在这里指定下面几个比较重要的参数
  parallelism: 3
  template:
    spec:    
      restartPolicy: Never
      containers:
      - image: s09g/random-error
        name: error-job

• activeDeadlineSeconds，设置 Pod 运行的超时时间
• backoffLimit，设置 Pod 的失败重试次数
• completions，Job 完成需要运行多少个 Success Pod，默认是 1 个
• parallelism，与 completions 相关，表示允许并发运行的 Pod 数量，避免过多占用资源，不指定就是一个一个启动。