I want to restart my kubernates pods after every 21 days - kubernetes

I want to restart my Kubernetes pods after every 21 days I want probably a crone job that can do that. That pod should be able to restart pods from all of my deployments.
I don't want to write any extra script for that is that possible ?
Thanks you .

If you want it to run every 21 days, no matter the day of month, then cron job doesn't support a simple, direct translation of that requirement and most other similar scheduling systems.
In that specific case you'd have to track the days yourself and calculate the next day it should run at by adding 21 days to the current date whenever the function runs.
My suggestion is :
if you want it to run at 00:00 every 21st day of the month:
Cron Job schedule is : 0 0 21 * * (at 00:00 on day-of-month 21).
Output :
If you want it to run at 12:00 every 21st day of the month:
Cron Job schedule is : 0 12 21 * * (at 12:00 on day-of-month 21).
Output :
Or else
If you want to add the 21 days yourself, you can refer and use setInterval to schedule a function to run at a specific time as below :
const waitSeconds = 1814400; // 21 days
function scheduledFunction() {
// Do something
}
// Run now
scheduledFunction();
// Run every 21 days
setInterval(scheduledFunction, waitSeconds);
For more information Refer this SO Link to how to schedule Pod restart.

Related

celery beat timezone problems

So, I have been using celery/beat for a number of years, and have been ofsetting manually, the schedule of my tasks due to DST issues etc. As my codebase has become larger, the script that I run to change the times is getting bigger and bigger, and I have decided to sort the problem out.
So in short, my system clock updates automatically, from my shell I can run:
┌─[luke#freebsd] - [~/py3-apps/intranet] - [Thu Mar 29, 12:24]
└─[$]> date
Thu Mar 29 12:37:22 BST 2018
So presently I have a task to run at 10:30am, it will run at 11:30am. So I thought this would be easy, I added the following to my configuration:
CELERY_TIMEZONE = Europe/London
CELERY_ENABLE_UTC = False
When I run my celery beat schedule, via:
celery worker --beat -A pyramid_celery.celery_app --ini development.ini -n celeryIntranetAPI
Now I thought this would solve my problems, however my cron tasks are still an hour behind, how can I make celery keep up with the system clock?
Note I have tried:
CELERY_TIMEZONE = UTC
CELERY_ENABLE_UTC = True
As per a few suggestions, but this did not work either.
Can anyone can shed some light on how I can link my celery cron timings to the system clock?
This was fixed in celery here: https://github.com/celery/celery/commit/be55de622381816d087993f1c7f9afcf7f44ab33
Turns out this was a bug with celery, fixed here

Fail2Ban not working on Ubuntu 16.04 (Date issues)

I have a problem with Fail2Ban
2018-02-23 18:23:48,727 fail2ban.datedetector [4859]: DEBUG Matched time template (?:DAY )?MON Day 24hour:Minute:Second(?:\.Microseconds)?(?: Year)?
2018-02-23 18:23:48,727 fail2ban.datedetector [4859]: DEBUG Got time 1519352628.000000 for "'Feb 23 10:23:48'" using template (?:DAY )?MON Day 24hour:Minute:Second(?:\.Microseconds)?(?: Year)?
2018-02-23 18:23:48,727 fail2ban.filter [4859]: DEBUG Processing line with time:1519352628.0 and ip:158.140.140.217
2018-02-23 18:23:48,727 fail2ban.filter [4859]: DEBUG Ignore line since time 1519352628.0 < 1519381428.727771 - 600
It says "ignoring Line" because the time skew is greater than the inspection period. However, this is not the case.
If indeed 1519352628.0 is derived from Feb 23, 10:23:48, then the other date: 1519381428.727771 must be wrong.
I have run tests for 'invalid user' hitting this repeatedly. But Fail2ban is always ignoring the line.
I am positive I am getting Filter Matches within 1 second.
This is Ubuntu 16.04 and Fail2ban 0.9.3
Thanks for any help you might have!
Looks like there is a time zone issue on your machine that might cause the confusion. Try to set the correct time zone and restart both rsyslogd and fail2ban.
Regarding your debug log:
1519352628.0 = Feb 23 02:23:48
-> timestamp parsed from line in log file with time Feb 23 10:23:48 - 08:00 time zone offset!
1519381428.727771 = Feb 23 10:23:48
-> timestamp of current time when fail2ban processed the log.
Coincidently this is the same time as the time in the log file. That's what makes it so confusing in this case.
1519381428.727771 - 600 = Feb 23 10:13:48
-> limit for how long to look backwards in time in the log file since you've set findtime = 10m in jail.conf.
Fail2ban 'correctly' ignores the log entry that appears to be older than 10 minutes, because of the set time zone -08:00.
btw:
If you need IPv6 support for banning, consider upgrading fail2ban to v0.10.x.
And there is also a brand new fail2ban version v0.11 (not yet marked stable, but running without issue for 1+ month on my machines) that has this wonderful new auto-increment bantime feature.

Nomad periodic job starts immediately

I have a nomad periodic job that has this in the job config:
periodic {
cron = "* */2 * * *"
prohibit_overlap = true
}
However, I find that when nomad finishes running the job (the job takes less than two hours), it more or less immediately starts it again (sometimes within 60 seconds). I expected it to start it after about two hours.
Why does that happen, and how can I make nomad start the job only every two hours?
You have * in minutes field, so your job will start every minute. You should change cron to 0 */2 * * *.

Bluemix: How to understand down time or low performance of the platform?

I am currently using a free account, that will eventually move to a subscription later this month. I created a space in Sydney region and yesterday evening (Feb 02, 2016 India +5:30) the delivery pipeline became unresponsive. In the build stage, I had a maven build, Junit testing and Appscan static code scan.
Here are the details:
Job ​'Build'​ in Stage ​'Build from GitHub'​ #27 has ​​SUCCEEDED​
​Triggered by ​
​geekays​​
Started: 3/2/16 12:29:59 PM UTC
Duration: 1 minute 7 seconds
The build generally takes couple of seconds otherwise.
Job ​'UnitTest'​ in Stage ​'Build from GitHub'​ #27 has ​​SUCCEEDED​
​
Triggered by ​
​geekays​​
Started: 3/2/16 12:31:08 PM UTC
Duration: 1 minute 3 seconds
The UT generally takes less than 10 seconds.
geekays | java-web-service BOT
7:02 PM
Job ​
'Static Code Analysis'​ in Stage ​'Build from GitHub'​ #27 has ​​FAILED​
​
Triggered by ​
​geekays​​
Started: 3/2/16 12:32:21 PM UTC
Duration: 1 hour 0 minutes 5 seconds
The static code analysis actually timed out after the maximum permissible limit of 59 minutes.
It generally takes less than 10 minutes.
Job ​'Static Code Analysis'​ in Stage ​'Build from GitHub'​ #30 has ​​SUCCEEDED​
​Triggered by ​
​pipeline​​
Started: 3/3/16 9:06:38 AM UTC
Duration: 5 minutes 54 seconds
How to understand and respond in such a situation? Is Bluemix team aware of the down time? Or is there an environment provided for free accounts that are not maintained for a better SLA?
I am trying to understand this for being able to propose Bluemix as a solution to my clients.
Generally speaking Bluemix team is alerted for all events with the platform and there is no difference between free and pay accounts in terms of environment.
Sudden events come either from monitoring systems or customers and are usually analyzed and resolved at the max priority.
Scheduled events like maintenance are announced at:
https://developer.ibm.com/bluemix/support/#status
Events related to specific services have to be sent by the customer to Bluemix Support that has SLA for taking in charge the tickets and let the service provider know about the problem.
Info about Bluemix Support SLA can be found in "SaaS Service handbook" in IBM Client Success Portal.

pymongo cursor getMore takes long time

I am having trouble with the time it takes for my python script to iterate a data set. The data set is about 40k documents. This is large enough to cause the pymongo cursor to issue multiple fetches which are internal and abstracted away from the developer. I simplified my script down as much as possible to demonstrate the problem:
from pymongo import Connection
import time
def main():
starttime = time.time()
cursor = db.survey_answers.find()
counter=0;
lastsecond=-1;
for entry in cursor:
if int(time.time()-starttime)!=lastsecond:
print "loop number:", counter, " seconds:",int(time.time()-starttime);
lastsecond= int(time.time()-starttime)
counter+=1;
print (time.time()-starttime), "seconds for the mongo query to get rows:",counter;
connection = Connection(APPSERVER)#either localhost or hostname depending on test
db = connection.beacon
if __name__ == "__main__":
main()
My set up is as follows. I have 4 separate hosts, one APPSERVER running mongos, and 3 other shard hosts with each being a primary replica set and secondary replica sets of the other two.
I can run this from one of the shard servers (with the connection pointing to the APPSERVER hostname) and I get:
loop number: 0 seconds: 0
loop number: 101 seconds: 2
loop number: 7343 seconds: 5
loop number: 14666 seconds: 8
loop number: 21810 seconds: 10
loop number: 28985 seconds: 13
loop number: 36078 seconds: 15
16.0257680416 seconds for the mongo query to get rows: 41541
So it's obvious what's going on here, the first batchsize of a cursor request is 100, and then each subsequent one is 4m worth of data which appears to be just over 7k documents for me. And each fetch costs 2-3 seconds!!!!
I thought I could fix this problem by moving my application closer to the mongos instance. I ran the above code on APPSERVER (with the connection pointing to localhost) hoping to decrease the network usage .... but it was worse!
loop number: 0 seconds: 0
loop number: 101 seconds: 9
loop number: 7343 seconds: 19
loop number: 14666 seconds: 28
loop number: 21810 seconds: 38
loop number: 28985 seconds: 47
loop number: 36078 seconds: 53
53.5974030495 seconds for the mongo query to get rows: 41541
The cursor sizes are exactly the same in both test, which is nice, but each cursor fetch costs 9-10 seconds here!!!
I know I have four separate hosts that need to communicate, so this can't be instant. But I will need to iterate over collections of maybe 10m records. At 2 seconds per 7k, that would take just shy of an hour! I can't have this!
Btw, I'm new to the python/mongo world, I'm used to php and mysql where I would expect this to process in a fraction of a second:
$q=mysql_query("select * from big_table");//let's say 10m rows here ....
$c=0;
while($r=mysql_fetch_rows($q))
$c++;
echo $c." rows examined";
Can somebody explain the gargantuan difference between the pymongo (~1 hour) and php/mysql (<1 sec) approaches I've presented? Thanks!
I was able to figure this out with the help of A. Jesse Jiryu Davis. It turns out I didn't have C extension installed. I wanted to run another test without the shards so I could rule out the network latency as an issue. I got a fresh clean host, set up mongo, imported my data, and ran my script and it took the same amount of time. So I know the sharding/replica sets didn't have anything to do with the problem.
Before the fix, I was able to print:
pymongo.has_c(): False
pymongo version 2.3
I then followed the instructions to install the dependencies for c extensions:
yum install gcc python-devel
Then I reinstalled the pymongo driver:
git clone git://github.com/mongodb/mongo-python-driver.git pymongo
cd pymongo/
python setup.py install
I reran my script and it now prints:
pymongo.has_c(): True
pymongo version 2.3+
And it takes about 1.8 seconds to run as opposed to the 16 above. That still seems long to fetch 40k records and iterate over them, but it's a significant improvement.
I will now run these updates on my prod (sharded, replica set) environment to hopefully see the same results.
**UPDATE**
I updated my pymongo driver on my prod environment and there was an improvement, though not as much. It took about 2.5-3.5 seconds over a few tests. I presume the sharding nature was the fault here. That still seems incredibly slow to iterate over 40k records.