Shulou(Shulou.com)05/31 Report--

Editor to share with you how to use Secret in kubernetes, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

One: brief introduction

Secret can be mounted as a data volume or exposed as an environment variable for use by containers in pod. They can also be used by other parts of the system without being directly exposed to the pod. For example, they can hold credentials, which the rest of the system should use to interact with external systems on your behalf.

For example, Secret:

ApiVersion: v1

Kind: Secret

Metadata:

Name: mysecret

Type: Opaque

Data:

Username: YWRtaW4=

Password: MWYyZDFlMmU2N2Rm

Two: use Secret files in Pod

1. Create a secret or use an existing secret. Multiple pod can reference the same secret.

two。 Modify the definition of your pod and add a volume under spec.volumes []. You can name this volume as you like, and its spec.volumes [] .secret.secretName must be equal to the name of the secret object.

3. Add spec.containers [] .volumeMounts [] to the container that needs to be used with the secret. Specify spec.containers [] .volumeMounts [] .readOnly = true and spec.containers [] .volumeMounts [] .mountPath as the unused directories that you want the secret to appear.

4. Modify your image and / or have the program look for files from that directory on the command line. Each key in Secret's data map becomes a file name under mountPath.

ApiVersion: v1

Kind: Pod

Metadata:

Name: mypod

Spec:

Containers:

-name: mypod

Image: redis

VolumeMounts:

-name: foo

MountPath: "/ etc/foo"

ReadOnly: true

Volumes:

-name: foo

Secret:

SecretName: mysecret

Each secret you want to use needs to be specified in the spec.volumes. If there are multiple containers in the pod, each container needs its own volumeMounts configuration block, but only one spec.volumes per secret.

You can package multiple files into one secret, or use multiple secret, as convenient as possible.

Three: map secret keys to the feature path

We can also control the path of the Secret key map in volume. You can use the spec.volumes [] .secret.items field to modify the destination path of each key:

ApiVersion: v1

Kind: Pod

Metadata:

Name: mypod

Spec:

Containers:

-name: mypod

Image: redis

VolumeMounts:

-name: foo

MountPath: "/ etc/foo"

ReadOnly: true

Volumes:

-name: foo

Secret:

SecretName: mysecret

Items:

-key: username

Path: my-group/my-username

The 1.username secret is stored in the / etc/foo/my-group/my-username file instead of / etc/foo/username.

2.password secret is not insinuated.

If spec.volumes [] .secret.items is used, only the key specified in items is mapped. To use all the key in secret, all of these must be listed in the items field. All listed keys must exist in the corresponding secret. Otherwise, the volume is not created.

Four: Secret file permissions

You can also specify the permission mode bit file that secret will have. If not specified, 0644 is used by default. You can specify the default mode for the entire secret volume and overwrite each key if desired.

ApiVersion: v1

Kind: Pod

Metadata:

Name: mypod

Spec:

Containers:

-name: mypod

Image: redis

VolumeMounts:

-name: foo

MountPath: "/ etc/foo"

Volumes:

-name: foo

Secret:

SecretName: mysecret

DefaultMode: 256

The secret will then be mounted to the / etc/foo directory, with 0400 permissions for all files created through that secret volume mount.

Note that the JSON specification does not support octal symbols, so use a value of 256 as the 0400 permission. If you use yaml instead of json as the pod, you can use octal symbols to specify permissions in a more natural way.

Fifth: consume secret values from Volume

In the container of the mounted secret volume, the secret key will be used as a file, and the value of the secret will be decoded using base-64 and stored in these files. This is the result of the command executed in the example container above:

$ls / etc/foo/

Username

Password

$cat / etc/foo/username

Admin

$cat / etc/foo/password

1f2d1e2e67df

Six: the mounted secret is automatically updated

When the secret that has been consumed in the volume is updated, the mapped key will also be updated. Kubelet checks to see if the mounted secret is up-to-date during periodic synchronization. However, it is using its local ttl-based cache to get the current secret value. As a result, the total delay from the time the secret is updated to the time the new secret is mapped to the pod can be as long as the kubelet sync period + ttl of the secret cache in kubelet.

Seven: Secret as an environmental variable

1. Create a secret or use an existing secret. Multiple pod can reference the same secret.

two。 Modify the Pod definition that you want to use secret key in each container, adding an environment variable for each secret key you want to use. The environment variable that consumes secret key should fill in the name of secret and type env [x] .valueFrom.secretKeyRef.

3. Modify the mirror or command line so that the program looks for values in the specified environment variables.

ApiVersion: v1

Kind: Pod

Metadata:

Name: secret-env-pod

Spec:

Containers:

-name: mycontainer

Image: redis

Env:

-name: SECRET_USERNAME

ValueFrom:

SecretKeyRef:

Name: mysecret

Key: username

-name: SECRET_PASSWORD

ValueFrom:

SecretKeyRef:

Name: mysecret

Key: password

RestartPolicy: Never

Eight: the Secret value in the consumption environment variable

In a container that consumes the environment variable secret, secret key is used as a regular environment variable containing the base-64 decrypted value of the secret data. This is the result of the command executed in the container from the example above:

$echo $SECRET_USERNAME

Admin

$echo $SECRET_PASSWORD

1f2d1e2e67df

Nine: use imagePullSecret

ImagePullSecret is a way to pass a secret containing the registry password of an Docker (or other) image to Kubelet, so you can pull a private image on behalf of your pod.

Ten: restrictions on using Secret

1. Verify the secret volume source to ensure that the specified object reference actually points to an object of type Secret. Therefore, you need to create a secret before any pod that depends on it.

The 2.Secret API object resides in the namespace. They can only be referenced by pod in the same namespace.

3. The size of each secret is limited to 1MB. This is to prevent creating a very large secret from running out of memory for apiserver and kubelet. However, creating many smaller secret can also run out of memory. More comprehensive restrictions secret's more comprehensive restrictions on memory use are planned capabilities.

4.Kubelet only supports secret for Pod obtained from API server. This includes any pod created using kubectl, or pod created indirectly through replication controller. It does not include pod created with the kubelet-- manifest-url flag, its-- config flag, or its REST API (these are not common methods for creating pod).

5. You must first create secret, and unless you mark them as optional, you must create a secret before using it as an environment variable in pod. A reference to a secret that does not exist will prevent it from starting.

6. Referencing a key that does not exist in a named key through secretKeyRef will prevent the startup.

7. The secret used to populate environment variables with envFrom, and key with environment variable names that are considered invalid will skip these keys. The pod will be allowed to start. There will be an event due to InvalidVariableNames, which will contain a list of invalid keys that have been skipped. This example shows a pod, which refers to the default / mysecret ConfigMap that contains two invalid keys, 1badkey and 2alsobad.

Eleventh: the relationship between Secret and the life cycle of Pod

When a Pod is created through API, the existence of the applied secret is not checked. Once the Pod is scheduled, kubelet attempts to get the value of the secret. If the secret is not available, or if a connection to the API server cannot be established temporarily, kubelet will retry periodically. Kubelet will report an event about pod and explain why it cannot start. Once the acquired secret,kubelet is created and mounted, a volume containing it is created. The pod container is not started until all pod volumes are installed.

The above is all the content of the article "how to use Secret in kubernetes". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.