You can filter Kubernetes namespaces in GKE by using labels. This allows you to categorize and select namespaces programmatically.

Some common ways to use labels on namespaces are:

• By environment (dev, prod, staging)
• By application
• By customer
• By developer team

To add a label to a namespace, you use the kubectl label command:

bash
kubectl label namespace my-namespace env=dev

This will add a label env=dev to the my-namespace namespace.

You can list namespaces with a specific label using:

bash
kubectl get namespaces -l env=dev

This will list only namespaces with the env=dev label.

Some other useful commands for filtering by labels are:

• kubectl delete namespaces -l env=dev - Delete all namespaces with env=dev
• kubectl get pods --namespace $(kubectl get namespaces -l env=dev -o jsonpath="{.items[0].metadata.name}") - Get pods in the first namespace with env=dev
• kubectl config set-context $(kubectl config current-context) --namespace=env=dev - Set the default namespace to one matching the env=dev label

You can label namespaces at creation time by including the labels in the YAML manifest:

yaml
apiVersion: v1
kind: Namespace
metadata:
name: my-namespace
labels:
env: dev

This will create the my-namespace namespace with the env=dev label.

Namespace labels are a useful way to organize your Kubernetes resources and filter them in GKE. Let me know if you have any other questions!

H

Hello

可以使用 pip list 来查看某个软件包是否已经安装。

例如,要检查 Flask 是否已经安装,可以运行:
bash
pip list | grep Flask

如果 Flask 已经安装,输出会包含:
Flask (1.1.2)

如果 Flask 未安装,则不会有任何输出。

所以,可以这样写一个判断来检查 Flask 是否安装:
bash
pip list | grep Flask > /dev/null
if [ $? -eq 0 ]; then
echo "Flask is installed!"
else
echo "Flask is not installed."
fi

这个判断的原理是:

1. 使用 pip list | grep Flask 搜索已安装的包列表,看是否包含 Flask
2. 如果搜索到了,由于我们重定向了输出到 /dev/null,所以什么输出也不会显示,此时 $? (上一命令的退出码)会等于 0
3. 如果未搜索到,grep 的退出码会不等于 0,所以我们可以判断 Flask 是否已安装
4. 根据 $? 的值,打印相应的提示来告知用户 Flask 是否已安装

这个小技巧在编写项目的安装脚本时非常有用,我们可以提前判断某些必要的依赖是否已经安装,如果未安装则进行提醒。

除此之外,pip list 命令的其他使用方式还有:

• pip list -o 只列出过时的包
• pip list -t 只列出某一特定版本的包
• pip list -u 同时列出可以升级的包

等等,这些在包管理时也同样很实用。

这个 YAML 定义了一个 Volume,通过 ConfigMapconfigmap 挂载的,以 nginx为名字,mountpath 路径为 /etc/nginx/nginx.conf。使用subpath: nginx.conf 指定使用配置文件的内容,覆盖默认的nginx.conf文件。

这个在实际中使用时,可以实现如下功能:

1. 通过 ConfigMap 为 nginx 提供自定义的配置文件,取代默认配置。

例如我们定义一个 ConfigMap:
yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-config
data:
nginx.conf: |
server {
listen 80;
location / {
proxy_pass http://app:8000;
}
}

然后通过上述 Volume 挂载,这个 ConfigMap 里的 nginx.conf 文件会覆盖 Pod 中 nginx 默认的配置文件。这样 nginx 就会使用我们自定义的配置启动。

2. 动态更新 nginx 配置

当 ConfigMap 的数据更新后,Volume 中的文件也会自动更新。所以我们可以通过更新 ConfigMap 来动态调整 nginx 的配置。

nginx 会自动加载最新配置并重新启动,这为 nginx 提供了配置的动态性。

3. 在不同环境有不同的 nginx 配置

我们可以为不同的环境定义不同的 ConfigMap,然后在不同环境的 Pod 中挂载不同的 ConfigMap 来使用不同的 nginx 配置。

这使得单个 Pod 定义可以灵活运用于不同的环境。

所以,通过这种 Volume 方式,结合 ConfigMap,我们可以轻松为 nginx 或其他软件提供自定义的配置文件,并实现配置的动态更新。

这是我们日常在 Kubernetes 中使用 nginx 及其他服务时的一个很实用的技能。理解和掌握它可以让我们在配置和维护这些服务的过程中事半功倍。

它还为我们提供一种简单灵活的方式,实现应用配置的动态变更,是一名熟练的 Kubernetes 使用者必备的技能之一。

所以值得我们在日常工作中积极理解和运用。迈向 Kubernetes 高手,这是一个很有必要的一步。

在 gunicorn 配置文件 gunicorn.conf.py 中,可以使用 raw_env 选项来指定ENVIRONMENT变量。

例如,我们可以这样设置:
python
raw_env = [
"TEST_ENV=some value",
]

这会使 gunicorn 在启动应用时,设置一个 TEST_ENV 的环境变量,值为 some value。

应用可以通过 os.environ["TEST_ENV"] 来获取这个环境变量的值。

raw_env 选项允许我们在 gunicorn 启动时,注入我们想要的任意环境变量到应用中。这在以下情况下非常有用:

1. 当我们的应用依赖某些环境变量时,我们可以通过 raw_env 设置,而不用在系统级别设置这些环境变量。这样可以使设置更加干净简洁。

2. 我们可以把一些敏感数据,如数据库用户名密码等,通过环境变量的形式注入到应用,而不用硬编码在代码中。这可以提高安全性。

3. 我们可以为不同的 gunicorn 实例设置不同的环境变量,以区分他们或实现不同的行为。

4. 环境变量是一个简单的方式,用来在应用和运维工具(如 gunicorn)之间传递配置信息。

除此之外,raw_env 选项也常与其他选项一起使用,例如:

• chdir:切换工作目录,这样环境变量的路径也会相对于工作目录
• daemon:以守护进程模式运行,这样设置的环境变量也会传递到守护进程中

等等。

所以,gunicorn 的 raw_env 选项为我们提供了一种简单的机制,可以轻松的在 gunicorn 启动时向应用注入环境变量,这是一个既简单又强大的配置手段。

理解和运用 raw_env 选项,可以让我们的应用在灵活性和安全性等方面有很大提高。

这里 is 一个 shell 脚本来实现这个过程:

bash
#!/bin/bash

获取最新镜像ID

IMAGE_ID=$(docker images -a | grep latest | head -1 | awk '{print $3}')

运行容器,端口映射8443到宿主机的8433端口

CONTAINER_ID=$(docker run -itd -p 8433:8443 $IMAGE_ID)

获取运行容器ID

CONTAINER_ID=$(docker ps -a | grep $IMAGE_ID | awk '{print $1}')

登陆到运行中的容器

docker exec -it $CONTAINER_ID bash

这个脚本的步骤如下:

1. 使用 docker images -a 获取最新的镜像ID,存储在 IMAGE_ID 变量

2. 使用 docker run 运行这个镜像,端口映射并保存运行的容器ID到 CONTAINER_ID 变量

3. 再次使用 docker ps -a 获取运行容器的ID,也保存到 CONTAINER_ID 变量

4. 使用 docker exec 登录到运行中的容器

这个脚本实现了你描述的功能 - 获取最新镜像并运行,获取运行中的容器ID,最后登录到容器中。

在Shell中，${3,,}是一种字符串操作，表示将变量$3中的所有字符转换为小写字母。具体来说，${parameter,,}表示将parameter中的所有字符转换为小写字母。例如，如果$3的值为HELLO，那么${3,,}就会将其转换为hello。这个操作符在需要进行字符串比较或者大小写不敏感的字符串匹配时非常有用。

在shell中,可以使用sed或者tr命令来去除NBSP。

使用sed:
bash
sed 's/ //g' input.txt > output.txt

使用tr:
bash
tr -d ' ' < input.txt > output.txt

举个例子,如果input.txt的内容是:
some   text   with   spaces

那么使用sed的输出会是:
some text with spaces

使用tr的输出会是:

some text with spaces

sed会将NBSP直接替换为空格,而tr会直接删除NBSP,导致相邻的空白字符聚合在一起。

除此之外,也可以写一个shell脚本来处理:
bash
#!/bin/bash

sed 's/ //g' input.txt | tr -s ' ' > output.txt

这个脚本先使用sed替换NBSP,然后 uses tr的 -s 参数删除多余空格,最后输出到output.txt。

所以总结来说,在shell中可以轻易使用sed,tr以及shell脚本来去除文本中的NBSP。

在 gunicorn.conf.py 配置文件中,可以使用 os.getenv() 函数来获取环境变量的值并用于配置。

例如,如果存在一个 WORKERS 环境变量,我们可以这样获取:
python
workers = os.getenv("WORKERS", 3) # 如果不存在,默认为 3

这会将 WORKERS 环境变量的值赋给 workers 配置,如果环境变量不存在,workers 会默认为 3。

这在以下情况下很有用:

1. 我们可以在系统环境中设置一些 gunicorn 配置,然后在 gunicorn.conf.py 中直接获取,而不用在两个地方重复设置相同配置。

2. 一些敏感数据,如数据库密码,我们可以设置为环境变量,然后在配置中获取,而不用把密码明文写在配置文件中。

3. 我们可以根据运行 gunicorn 的主机设置不同的环境变量,实现动态的配置。例如主机不同设置不同的绑定地址等。

4. 使配置更简单灵活,环境变量提供一种简单方法在 gunicorn 和系统环境之间共享配置。

除 os.getenv() 之外,我们还可以使用:

• os.environ 直接获取所有的环境变量
• os.environ.get("KEY") 作为 os.getenv() 的替代方法

例如:
python
db_user = os.environ.get("DB_USER", "root")
db_pass = os.environ["DB_PASS"]
all_env = os.environ # 获取全部环境变量

所以,通过 os 模块,gunicorn.conf.py 可以很容易的从环境变量中获取值并用于配置 gunicorn。
这也使 gunicorn 与系统环境可以更好的结合,应用也可以通过设置环境变量来影响 gunicorn 的配置。

理解这种配置方式的优点,可以让我们在日常 gunicorn 配置过程中做到心中有数,灵活运用,简单高效。常用的 gunicorn 配置都可以这种方式实现,这是一个精通 gunicorn 不可或缺的技能。

掌握它,可以让我们在 gunicorn 配置过程中事半功倍,大大提高工作效率。

CA与自签名

制作CA私钥

openssl genrsa -out ca.key 2048

制作CA公钥/根证书

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

Common Name 随意填写；其它填写”.”

//////
服务器端证书

制作服务器私钥

openssl genrsa -out server.pem 1024
openssl rsa -in server.pem -out server.key

生成签发请求

openssl req -new -key server.pem -out server.csr

Common Name填写访问服务器时域名，配置nginx时用到，不能与CA的相同其它填写”.”

用CA签发证书

openssl x509 -req -sha256 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 -out server.crt

服务器端的证书和客户端的证书签发证书的过程其实是完全一样的，只是这里的命名上稍微做了一点点区别

///////
客户端证书

制作私钥

openssl genrsa -out client.pem 1024
openssl rsa -in client.pem -out client.key

生成签发请求

openssl req -new -key client.pem -out client.csr

Common Name填写访问服务器时域名，配置nginx时用到，不能与CA的相同 其它填写”.”

用CA签发

openssl x509 -req -sha256 -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 -out client.crt

使用浏览器访问时，需要生成p12格式的客户端证书

openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12

///////
配置NGINX

配置https双向认证的主要配置

listen 443 ssl;
server_name hostName;
server_tokens off;
ssl on;
ssl_certificate server.crt; # server证书公钥
ssl_certificate_key server.key; # server私钥
ssl_client_certificate ca.crt; # 根级证书公钥，用于验证各个二级client
ssl_verify_client on; # 开启客户端证书验证

配置好后重新加载nginx

service nginx reload
///////
测试

命令行Curl测试

curl --insecure --key client.key --cert client.crt hostName

收到网页信息，成功

浏览器访问测试

把client.p12导入到浏览器的https配置中，访问站点建立连接的时候nginx会
要求客户端把这个证书发给自己验证，如果没有这个证书就拒绝访问。

///////
如何获取证书中的用户邮箱信息

nginx ssl模块有个变量：$ssl_client_s_dn，这个变量存储的是认证信息，内容格式如下： emailAddress=client email,CN=server host name,通过在nginx中使用该变量配置个请求头，可以在 业务代码中获取这个信息，然后从其中解析出邮箱信息。
参考链接

https://segmentfault.com/a/1190000002866627