Multiple postures for handling container time in k8s environment

Immortal Technology 2021-09-15 08:44:45

 

 

k8s A variety of postures to deal with container time problems in the environment _ environment variable

1、 Background Overview

stay Linux In the environment , When installing the operating system by default, you need to correctly set the time zone of the system to the current time zone

In a container environment , In addition to business image , In many cases, we use official images or third-party images , And these images are generally not made by Chinese . So when using these images , Naturally there will be a problem , That is, the default time zone of the container image is incorrect

In short , Processing time is required in a container environment ( The time zone ) The causes of the problem are generally

  • Time is wrong , And the right ( For example, Beijing time ) There is a deviation
  • The time zone is wrong , The mirror default time zone does not match the current time zone
  • Some special businesses need to modify the time temporarily . For example, e-commerce spike business , Set the time to lead or lag , Test the time control function of the business internally

2、 Hardware clock and system time

Let's take a look at the operating system and how the container gets time

The clock is generally divided into hardware clock (RTC,Real Time Clock) And operating system clock (OS,System Clock)

The hardware clock runs on cpu The program on is independent and irrelevant , Even after the server is shut down, it can still run normally , This ensures the normal operation of the server , Hardware time also has various names , for example :hardware clock, real time clock, RTC, BIOS clock as well as CMOS clock etc. , At present, the mainstream servers adopt RTC Chip implementation

Operating system time is called system clock or system time , This is the time that I often come into contact with in the system , It is also the time used by the application to perform time-related operations , It only exists when the system is running , The record form is UTC Time (the number of seconds since 00:00:00 January 1, 1970 UTC)

Relationship between hardware clock and system time

Hardware clock is the necessary hardware to ensure that the timing can still be normal after the operating system is shut down , The system time is the time we often use in our daily operation , Only when the operating system is initialized , The operating system will go RTC Get the value of the hardware clock from the chip , Then there is independent operation and independent timing

The operation mechanism of the clock is as follows

k8s A variety of postures to deal with container time problems in the environment _docker_02

3、Linux Modify time in

Time dependent time standard , There are two criteria for the representation of time :localtime and UTC(Coordinated Universal Time)

  • UTC It's a time zone independent global time standard . Despite conceptual differences ,UTC and GMT ( Greenwich mean time ) It's the same
  • localtime The standard depends on the current time zone

The time standard is set by the operating system ,Windows By default localtime,Mac OS By default UTC and UNIX Series of operating systems, both . Use Linux when , It is best to set the hardware clock to UTC standard , And use... In all operating systems . such Linux The system can automatically adjust the setting of daylight saving time , And if you use localtime Standard, then the system time will not be automatically adjusted according to daylight saving time

You can check the current settings with the following command , Terminal execution

timedatectl status | grep local

  • 1.

Hardware time available hwclock Command settings , Set hardware time to localtime

timedatectl set-local-rtc 1

  • 1.

Hardware time set to UTC, Terminal execution

timedatectl set-local-rtc 0

  • 1.

The above commands are generated automatically /etc/adjtime, There is no need to set it separately

In everyday use , The modification time is generally passed date Modification date time , adopt hwclock Calibrate hardware clock

It's mentioned here Daylight saving time , Share another interesting thing , Maybe most people don't know yet , After liberation, our country implemented daylight saving time

k8s A variety of postures to deal with container time problems in the environment _ system time _03

4、 Try modifying the time in the container

Can I pass through the container date Modification date time , adopt hwclock Calibrate hardware clock ?

In fact, it is impossible , If you modify the time through the default permission inside the container, an error will be reported

k8s A variety of postures to deal with container time problems in the environment _ environment variable _04

This is because container isolation is based on Linux Of Capability Realized by mechanism , You can add --privileged or --cap-add SYS_TIME To achieve the purpose , But it is not recommended , Because this will directly affect the time of the host where the container is located

Linux In the kernel timekeeper Set to global variable , So just modify the system time , This impact is at the kernel level , So in docker In the implementation of, it is forbidden to modify the time in the container by default , Because the difference between container and virtualization is whether to share the kernel , This means that once the time is modified in the container , The impact is global

5、 Various postures for dealing with time problems

There was a lot of talk ahead , It's time to get to the point

stay k8s How to deal with the container in the environment , That is to say pod Time for

Before processing , First of all pod The host machine node The time synchronization zone is set normally , Same as current time

# timedatectl
Local time: Thu 2021-08-26 00:16:28 CST
Universal time: Thu 2021-08-26 16:16:28 UTC
RTC time: Thu 2021-08-26 16:16:28
Time zone: Asia/Shanghai (CST, +0800)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a

  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.

Let's share a variety of ways to deal with container time , It is mainly divided into two directions , Calibration time and adjustment time

5.1 stay Dockerfile Add time zone to

For ease of operation , Once and for all , It can be done by Dockerfile Add time zone to

# Set timezone
RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
&& echo "Asia/Shanghai" > /etc/timezone

  • 1.
  • 2.
  • 3.

This method is very convenient for self-made business images , It's easy to operate , After all, you only need to pass Dockerfile Create a business image and add this content

5.2 Mount the time zone file to Pod in

In defining pod When the upper controller , Add a volume to mount the time zone , Mount the time zone file of the host

...
containers:
- name: xxx
...
volumeMounts:
- name: timezone
mountPath: /etc/localtime
volumes:
- name: timezone
hostPath:
path: /usr/share/zoneinfo/Asia/Shanghai

  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.

5.3 Define time zone through environment variable

alike , In defining pod When the upper controller , Add an environment variable that specifies the time zone

TZ The environment variable is used to set the time zone . It is used by various time functions to calculate relative to the global standard time UTC( Formerly known as Greenwich mean time GMT) Time for . The format is specified by the operating system

...
containers:
- name: xxx
...
env:
- name: TZ
value: Asia/Shanghai

  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.

5.4 adopt PodPreset Global modification time

Often encounter modification Pod Time zone requirements , All are required Pod All in the same time zone , In the previous way, we need to treat each Pod Do this manually , stay k8s A better way in this environment is to use PodPreset To preset the time ,PodPreset You can inject some information when the container starts

PodPreset stay 1.20 Version removed , I didn't find any reason

If it is 1.20 Previous versions , The specific configuration method is as follows

First enable PodPreset

# stay kube-apiserver Launch parameters -runtime-config increase settings.k8s.io/v1alpha1=true;
—runtime-config=rbac.authorization.k8s.io/v1alpha1=true,settings.k8s.io/v1alpha1=true
# And then in --admission-control increase PodPreset Enable
—admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota,PodPreset

  • 1.
  • 2.
  • 3.
  • 4.

Restart the service after modification , Check to see if there is podpresets api type

kubectl api-resources |grep podpresets

  • 1.

establish PodPresents Resource objects

apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: tz-env
spec:
selector:
matchLabels:
env:
- name: TZ
values: Asia/Shanghai

  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.

What needs to be noted here is , It must be written selector...matchLabels, Even though matchLabels It's empty , Indicates that it applies to all containers , Create the above resource object , Then create an ordinary Pod You can check whether the above is injected TZ This environment variable

It should be noted that ,PodPreset yes namespace Level object , Its scope can only be containers under the same namespace

5.5 Adjust time to preset value

The above methods are used to calibrate the time , If you need to pod Adjustment time in container , There is also a solution , The purpose is to adjust the time to a preset time

The main principle of the method here is OS Level intercept system time spoofing application , The implementation returns any time to the application layer

The main idea of interception is based on the loading of dynamic library , use LD_PRELOAD Mechanism , Implement this method and compile it into a dynamic library, which overrides the original method according to the loading order of the dynamic library

There has been a  libfaketime project Realization , According to its documentation , The main steps are

  • Clone code for compilation
git clone https://github.com/wolfcw/libfaketime.git
cd libfaketime && make install

  • 1.
  • 2.
  • After compilation , Copy the library file to the container
docker cp /usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 e6e239e5fba7:/usr/local/lib/

  • 1.
  • Then enter the container and execute the command to change the environment variable
export LD_PRELOAD=/usr/local/lib/libfaketime.so.1 FAKETIME="-5d"

  • 1.

In a container environment , Manually following the above steps can take effect , The only drawback is that once the container is restarted, it will fail

In the container (k8s Environmental Science ) How to solve ?

The previous steps can pass the compiled library file through dockerfile Package into mirror , Modify the time if necessary , Only need Pod Add environment variables when defining the controller

...
containers:
- name: xxx
...
env:
- name: LD_PRELOAD
value: "/usr/local/lib/libfaketime.so.1"
- name: FAKETIME
value: "-5d"

  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.

Another idea is , Time adjustment is usually temporary , And more pod Time synchronization requirements , take LD_PRELOAD Whether the application is opened or not is placed in the running environment of the application , use configmap As the standard of application time , Change time value faketime As configmap

apiVersion: v1
kind: ConfigMap
metadata:
name: faketimerc
namespace: default
data:
faketimerc: |
+10d

  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.

All the last pod Are subject to volume Mount the in the form of configmap

...
containers:
- name: xxx
...
volumeMounts:
- name: faketimerc
mountPath: /etc/faketimerc
volumes:
- name: faketimerc
configMap:
name: faketimerc
items:
- key: faketimerc
path: faketimerc

  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.

See you ~

 
 
 
 
Please bring the original link to reprint ,thank
Similar articles

2021-09-15

2021-09-15