ਸਮਾਂ-ਸਾਰਣੀ ਨਿਯਮਾਂ ਦੇ ਇੱਕ ਕਸਟਮ ਸੈੱਟ ਦੇ ਨਾਲ ਇੱਕ ਵਾਧੂ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਬਣਾਉਣਾ

ਕੁਬੇ-ਸ਼ਡਿਊਲਰ ਕੁਬਰਨੇਟਸ ਦਾ ਇੱਕ ਅਨਿੱਖੜਵਾਂ ਹਿੱਸਾ ਹੈ, ਜੋ ਕਿ ਨਿਰਧਾਰਤ ਨੀਤੀਆਂ ਦੇ ਅਨੁਸਾਰ ਨੋਡਾਂ ਵਿੱਚ ਪੌਡਾਂ ਨੂੰ ਤਹਿ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਅਕਸਰ, ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦੇ ਸੰਚਾਲਨ ਦੇ ਦੌਰਾਨ, ਸਾਨੂੰ ਇਹ ਸੋਚਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਕਿ ਪੌਡਾਂ ਨੂੰ ਤਹਿ ਕਰਨ ਲਈ ਕਿਹੜੀਆਂ ਨੀਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਡਿਫੌਲਟ ਕਿਊਬ-ਸਡਿਊਲਰ ਦੀਆਂ ਨੀਤੀਆਂ ਦਾ ਸੈੱਟ ਜ਼ਿਆਦਾਤਰ ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮਾਂ ਲਈ ਢੁਕਵਾਂ ਹੁੰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਸਾਡੇ ਲਈ ਪੌਡਾਂ ਦੀ ਵੰਡ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵਧੀਆ ਬਣਾਉਣਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਸ ਕੰਮ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੇ ਦੋ ਤਰੀਕੇ ਹਨ:

1. ਨਿਯਮਾਂ ਦੇ ਇੱਕ ਕਸਟਮ ਸੈੱਟ ਦੇ ਨਾਲ ਇੱਕ ਕਿਊਬ-ਸਡਿਊਲਰ ਬਣਾਓ
2. ਆਪਣਾ ਖੁਦ ਦਾ ਸ਼ਡਿਊਲਰ ਲਿਖੋ ਅਤੇ ਇਸਨੂੰ API ਸਰਵਰ ਬੇਨਤੀਆਂ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸਿਖਾਓ

ਇਸ ਲੇਖ ਵਿੱਚ, ਮੈਂ ਸਾਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚੋਂ ਇੱਕ 'ਤੇ ਹਾਰਥਸ ਦੀ ਅਸਮਾਨ ਸਮਾਂ-ਸਾਰਣੀ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਪਹਿਲੇ ਬਿੰਦੂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਵਰਣਨ ਕਰਾਂਗਾ.

ਕਿਊਬ-ਸਡਿਊਲਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਬਾਰੇ ਇੱਕ ਸੰਖੇਪ ਜਾਣ-ਪਛਾਣ

ਇਹ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਪੌਡਾਂ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਤਹਿ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਨਹੀਂ ਹੈ - ਇਹ ਸਿਰਫ ਨੋਡ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ ਜਿਸ 'ਤੇ ਪੌਡ ਲਗਾਉਣਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਕਿਊਬ-ਸਡਿਊਲਰ ਦੇ ਕੰਮ ਦਾ ਨਤੀਜਾ ਨੋਡ ਦਾ ਨਾਮ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਅਨੁਸੂਚੀ ਬੇਨਤੀ ਲਈ API ਸਰਵਰ ਨੂੰ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇਸਦਾ ਕੰਮ ਖਤਮ ਹੁੰਦਾ ਹੈ।

ਪਹਿਲਾਂ, ਕਿਊਬ-ਸਡਿਊਲਰ ਨੋਡਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਪੋਡ ਨੂੰ ਪੂਰਵ-ਅਨੁਮਾਨ ਦੀਆਂ ਨੀਤੀਆਂ ਦੇ ਅਨੁਸਾਰ ਤਹਿ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਅੱਗੇ, ਇਸ ਸੂਚੀ ਵਿੱਚੋਂ ਹਰੇਕ ਨੋਡ ਨੂੰ ਤਰਜੀਹਾਂ ਦੀਆਂ ਨੀਤੀਆਂ ਦੇ ਅਨੁਸਾਰ ਕੁਝ ਅੰਕ ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਵੱਧ ਤੋਂ ਵੱਧ ਅੰਕਾਂ ਵਾਲਾ ਨੋਡ ਚੁਣਿਆ ਗਿਆ ਹੈ। ਜੇ ਉੱਥੇ ਨੋਡਸ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਵੱਧ ਤੋਂ ਵੱਧ ਸਕੋਰ ਇੱਕੋ ਹੈ, ਤਾਂ ਇੱਕ ਬੇਤਰਤੀਬ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ। ਪੂਰਵ-ਅਨੁਮਾਨ (ਫਿਲਟਰਿੰਗ) ਅਤੇ ਤਰਜੀਹਾਂ (ਸਕੋਰਿੰਗ) ਨੀਤੀਆਂ ਦੀ ਇੱਕ ਸੂਚੀ ਅਤੇ ਵਰਣਨ ਵਿੱਚ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਦਸਤਾਵੇਜ਼.

ਸਮੱਸਿਆ ਦੇ ਸਰੀਰ ਦਾ ਵਰਣਨ

Nixys 'ਤੇ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਵੱਖ-ਵੱਖ Kubernetes ਕਲੱਸਟਰਾਂ ਦੇ ਰੱਖ-ਰਖਾਅ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਸਾਨੂੰ ਪਹਿਲਾਂ ਹਾਲ ਹੀ ਵਿੱਚ ਪੋਡਾਂ ਨੂੰ ਤਹਿ ਕਰਨ ਦੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ, ਜਦੋਂ ਸਾਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਸਮੇਂ-ਸਮੇਂ ਦੇ ਕਾਰਜਾਂ (~ 100 ਕਰੋਨਜੌਬ ਸੰਸਥਾਵਾਂ) ਨੂੰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਸੀ। ਸਮੱਸਿਆ ਦੇ ਵਰਣਨ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸਰਲ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਦੀ ਉਦਾਹਰਣ ਦੇਵਾਂਗੇ, ਜਿਸ ਵਿੱਚ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਇੱਕ ਵਾਰ ਇੱਕ ਕ੍ਰੋਨ ਟਾਸਕ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, CPU ਉੱਤੇ ਕੁਝ ਲੋਡ ਬਣਾਉਂਦਾ ਹੈ। ਕ੍ਰੋਨ ਟਾਸਕ ਨੂੰ ਚਲਾਉਣ ਲਈ, ਬਿਲਕੁਲ ਇੱਕੋ ਜਿਹੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਾਲੇ ਤਿੰਨ ਨੋਡ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਸਨ (ਹਰੇਕ 'ਤੇ 24 vCPUs)।

ਇਸ ਦੇ ਨਾਲ ਹੀ, ਇਹ ਕਹਿਣਾ ਅਸੰਭਵ ਹੈ ਕਿ ਕ੍ਰੋਨਜੌਬ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗੇਗਾ, ਕਿਉਂਕਿ ਇਨਪੁਟ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਲਗਾਤਾਰ ਬਦਲ ਰਹੀ ਹੈ। ਔਸਤਨ, ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਦੇ ਸਾਧਾਰਨ ਸੰਚਾਲਨ ਦੌਰਾਨ, ਹਰੇਕ ਨੋਡ 3-4 ਜੌਬ ਉਦਾਹਰਨਾਂ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ, ਜੋ ਹਰੇਕ ਨੋਡ ਦੇ CPU 'ਤੇ ~20-30% ਲੋਡ ਬਣਾਉਂਦੇ ਹਨ:

ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਕਈ ਵਾਰ ਕ੍ਰੋਨ ਟਾਸਕ ਪੌਡ ਤਿੰਨ ਨੋਡਾਂ ਵਿੱਚੋਂ ਇੱਕ 'ਤੇ ਤਹਿ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ। ਭਾਵ, ਕਿਸੇ ਸਮੇਂ, ਕਿਸੇ ਇੱਕ ਨੋਡ ਲਈ ਇੱਕ ਵੀ ਪੌਡ ਦੀ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਈ ਗਈ ਸੀ, ਜਦੋਂ ਕਿ ਦੂਜੇ ਦੋ ਨੋਡਾਂ 'ਤੇ ਟਾਸਕ ਦੀਆਂ 6-8 ਕਾਪੀਆਂ ਚੱਲ ਰਹੀਆਂ ਸਨ, ਜਿਸ ਨਾਲ CPU ਲੋਡ ਦਾ ~ 40-60% ਬਣ ਰਿਹਾ ਸੀ:

ਸਮੱਸਿਆ ਬਿਲਕੁਲ ਬੇਤਰਤੀਬੇ ਬਾਰੰਬਾਰਤਾ ਦੇ ਨਾਲ ਦੁਹਰਾਈ ਜਾਂਦੀ ਹੈ ਅਤੇ ਕਦੇ-ਕਦਾਈਂ ਕੋਡ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ ਦੇ ਰੋਲ ਆਊਟ ਕੀਤੇ ਜਾਣ ਦੇ ਪਲ ਨਾਲ ਸਬੰਧਿਤ ਹੁੰਦੀ ਹੈ।

ਕਿਊਬ-ਸਡਿਊਲਰ ਲੌਗਿੰਗ ਲੈਵਲ ਨੂੰ ਲੈਵਲ 10 (-v=10) ਤੱਕ ਵਧਾ ਕੇ, ਅਸੀਂ ਇਹ ਰਿਕਾਰਡ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕਿ ਮੁਲਾਂਕਣ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਹਰੇਕ ਨੋਡ ਨੇ ਕਿੰਨੇ ਪੁਆਇੰਟ ਹਾਸਲ ਕੀਤੇ। ਸਾਧਾਰਨ ਪਲੈਨਿੰਗ ਓਪਰੇਸ਼ਨ ਦੌਰਾਨ, ਲੌਗਸ ਵਿੱਚ ਹੇਠ ਲਿਖੀ ਜਾਣਕਾਰੀ ਦੇਖੀ ਜਾ ਸਕਦੀ ਹੈ:

resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1387 millicores 4161694720 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1347 millicores 4444810240 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1387 millicores 4161694720 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1687 millicores 4790840320 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1347 millicores 4444810240 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1687 millicores 4790840320 memory bytes, score 9
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: NodeAffinityPriority, Score: (0)                                                                                       
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node01: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: TaintTolerationPriority, Score: (10)                                                                                   
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node02: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node01: SelectorSpreadPriority, Score: (10)                                                                                                        
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node03: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node02: SelectorSpreadPriority, Score: (10)                                                                                                        
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node03: SelectorSpreadPriority, Score: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:781] Host Node01 => Score 100043                                                                                                                                                                        
generic_scheduler.go:781] Host Node02 => Score 100043                                                                                                                                                                        
generic_scheduler.go:781] Host Node03 => Score 100043

ਉਹ. ਲੌਗਸ ਤੋਂ ਪ੍ਰਾਪਤ ਜਾਣਕਾਰੀ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਹਰੇਕ ਨੋਡ ਨੇ ਅੰਤਮ ਅੰਕਾਂ ਦੀ ਬਰਾਬਰ ਸੰਖਿਆ ਪ੍ਰਾਪਤ ਕੀਤੀ ਅਤੇ ਯੋਜਨਾਬੰਦੀ ਲਈ ਇੱਕ ਬੇਤਰਤੀਬ ਇੱਕ ਚੁਣਿਆ ਗਿਆ। ਸਮੱਸਿਆ ਵਾਲੀ ਯੋਜਨਾਬੰਦੀ ਦੇ ਸਮੇਂ, ਲੌਗ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੇ ਸਨ:

resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1587 millicores 4581125120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1087 millicores 3532549120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1587 millicores 4581125120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 987 millicores 3322833920 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 987 millicores 3322833920 memory bytes, score 9 
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1087 millicores 3532549120 memory bytes, score 9
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node03: InterPodAffinityPriority, Score: (0)                                                                                                        
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node02: InterPodAffinityPriority, Score: (0)                                                                                                        
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node01: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node03: SelectorSpreadPriority, Score: (10)                                                                                                        
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node02: SelectorSpreadPriority, Score: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node01: SelectorSpreadPriority, Score: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: TaintTolerationPriority, Score: (10)                                                                                   
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:781] Host Node03 => Score 100041                                                                                                                                                                        
generic_scheduler.go:781] Host Node02 => Score 100041                                                                                                                                                                        
generic_scheduler.go:781] Host Node01 => Score 100038

ਜਿਸ ਤੋਂ ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਨੋਡਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੇ ਦੂਜਿਆਂ ਨਾਲੋਂ ਘੱਟ ਅੰਤਮ ਅੰਕ ਪ੍ਰਾਪਤ ਕੀਤੇ, ਅਤੇ ਇਸਲਈ ਯੋਜਨਾਬੰਦੀ ਸਿਰਫ ਦੋ ਨੋਡਾਂ ਲਈ ਕੀਤੀ ਗਈ ਸੀ ਜੋ ਵੱਧ ਤੋਂ ਵੱਧ ਸਕੋਰ ਪ੍ਰਾਪਤ ਕਰਦੇ ਸਨ। ਇਸ ਤਰ੍ਹਾਂ, ਸਾਨੂੰ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਯਕੀਨ ਹੋ ਗਿਆ ਸੀ ਕਿ ਸਮੱਸਿਆ ਪੌਡਾਂ ਦੀ ਸਮਾਂ-ਸਾਰਣੀ ਵਿੱਚ ਹੀ ਹੈ।

ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਅਗਲਾ ਐਲਗੋਰਿਦਮ ਸਾਡੇ ਲਈ ਸਪੱਸ਼ਟ ਸੀ - ਲੌਗਸ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ, ਸਮਝੋ ਕਿ ਨੋਡ ਨੇ ਕਿਹੜੀ ਤਰਜੀਹ ਨਾਲ ਅੰਕ ਨਹੀਂ ਬਣਾਏ ਅਤੇ, ਜੇ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਡਿਫੌਲਟ ਕਿਊਬ-ਸਡਿਊਲਰ ਦੀਆਂ ਨੀਤੀਆਂ ਨੂੰ ਅਨੁਕੂਲ ਕਰੋ। ਹਾਲਾਂਕਿ, ਇੱਥੇ ਸਾਨੂੰ ਦੋ ਮਹੱਤਵਪੂਰਨ ਮੁਸ਼ਕਲਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ:

1. ਅਧਿਕਤਮ ਲੌਗਿੰਗ ਪੱਧਰ (10) 'ਤੇ, ਸਿਰਫ ਕੁਝ ਤਰਜੀਹਾਂ ਲਈ ਪ੍ਰਾਪਤ ਕੀਤੇ ਅੰਕ ਪ੍ਰਤੀਬਿੰਬਿਤ ਹੁੰਦੇ ਹਨ। ਲੌਗਸ ਦੇ ਉਪਰੋਕਤ ਅੰਸ਼ਾਂ ਵਿੱਚ, ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਲੌਗਸ ਵਿੱਚ ਪ੍ਰਤੀਬਿੰਬਿਤ ਸਾਰੀਆਂ ਤਰਜੀਹਾਂ ਲਈ, ਨੋਡ ਆਮ ਅਤੇ ਸਮੱਸਿਆ ਅਨੁਸੂਚੀ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਅੰਕ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ, ਪਰ ਸਮੱਸਿਆ ਦੀ ਯੋਜਨਾਬੰਦੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਅੰਤਮ ਨਤੀਜਾ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਇਹ ਸਿੱਟਾ ਕੱਢ ਸਕਦੇ ਹਾਂ ਕਿ ਕੁਝ ਤਰਜੀਹਾਂ ਲਈ, ਸਕੋਰਿੰਗ "ਪਰਦੇ ਦੇ ਪਿੱਛੇ" ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸਾਡੇ ਕੋਲ ਇਹ ਸਮਝਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ ਕਿ ਕਿਸ ਤਰਜੀਹ ਲਈ ਨੋਡ ਨੂੰ ਅੰਕ ਨਹੀਂ ਮਿਲੇ ਹਨ। ਅਸੀਂ ਇਸ ਸਮੱਸਿਆ ਦਾ ਵਿਸਥਾਰ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਹੈ ਮੁੱਦੇ репозитория Kubernetes на Github. На момент написания статьи был получен ответ от разработчиков, что поддержка логирования будет добавлена в обновлениях Kubernetes v1.15,1.16 и 1.17.
2. ਇਹ ਸਮਝਣ ਦਾ ਕੋਈ ਆਸਾਨ ਤਰੀਕਾ ਨਹੀਂ ਹੈ ਕਿ ਕੁਬੇ-ਸਡਿਊਲਰ ਵਰਤਮਾਨ ਵਿੱਚ ਪਾਲਿਸੀਆਂ ਦੇ ਕਿਹੜੇ ਖਾਸ ਸੈੱਟ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਹਾਂ, ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਇਹ ਸੂਚੀ ਸੂਚੀਬੱਧ ਹੈ, ਪਰ ਇਸ ਵਿੱਚ ਇਹ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੈ ਕਿ ਹਰੇਕ ਤਰਜੀਹ ਨੀਤੀ ਨੂੰ ਕਿਹੜੇ ਖਾਸ ਵਜ਼ਨ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਹਨ। ਤੁਸੀਂ ਵਜ਼ਨ ਦੇਖ ਸਕਦੇ ਹੋ ਜਾਂ ਡਿਫਾਲਟ ਕਿਊਬ-ਸਡਿਊਲਰ ਦੀਆਂ ਨੀਤੀਆਂ ਨੂੰ ਸਿਰਫ਼ ਵਿੱਚ ਹੀ ਸੰਪਾਦਿਤ ਕਰ ਸਕਦੇ ਹੋ ਸਰੋਤ ਕੋਡ.

ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਇੱਕ ਵਾਰ ਜਦੋਂ ਅਸੀਂ ਇਹ ਰਿਕਾਰਡ ਕਰਨ ਦੇ ਯੋਗ ਹੋ ਗਏ ਸੀ ਕਿ ਇੱਕ ਨੋਡ ਨੂੰ ImageLocalityPriority ਨੀਤੀ ਦੇ ਅਨੁਸਾਰ ਪੁਆਇੰਟ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੋਏ, ਜੋ ਇੱਕ ਨੋਡ ਨੂੰ ਪੁਆਇੰਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੇਕਰ ਇਸ ਕੋਲ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਚਲਾਉਣ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਜ਼ਰੂਰੀ ਚਿੱਤਰ ਹੈ। ਭਾਵ, ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਰੋਲ ਆਊਟ ਕੀਤਾ ਗਿਆ ਸੀ, ਕ੍ਰੋਨ ਟਾਸਕ ਦੋ ਨੋਡਾਂ 'ਤੇ ਚੱਲਣ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋ ਗਿਆ, ਡੌਕਰ ਰਜਿਸਟਰੀ ਤੋਂ ਉਹਨਾਂ ਲਈ ਇੱਕ ਨਵੀਂ ਚਿੱਤਰ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨਾ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੋ ਨੋਡਾਂ ਨੇ ਤੀਜੇ ਦੇ ਮੁਕਾਬਲੇ ਇੱਕ ਉੱਚ ਫਾਈਨਲ ਸਕੋਰ ਪ੍ਰਾਪਤ ਕੀਤਾ। .

ਜਿਵੇਂ ਕਿ ਮੈਂ ਉੱਪਰ ਲਿਖਿਆ ਹੈ, ਲੌਗਸ ਵਿੱਚ ਸਾਨੂੰ ImageLocalityPriority ਨੀਤੀ ਦੇ ਮੁਲਾਂਕਣ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਇਸਲਈ ਸਾਡੀ ਧਾਰਨਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ ਦੇ ਨਾਲ ਚਿੱਤਰ ਨੂੰ ਤੀਜੇ ਨੋਡ 'ਤੇ ਸੁੱਟ ਦਿੱਤਾ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਸਮਾਂ-ਸਾਰਣੀ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ। . ਇਹ ਬਿਲਕੁਲ ਸਹੀ ਰੂਪ ਵਿੱਚ ImageLocalityPriority ਨੀਤੀ ਦੇ ਕਾਰਨ ਸੀ ਕਿ ਸਮਾਂ-ਸਾਰਣੀ ਸਮੱਸਿਆ ਨੂੰ ਬਹੁਤ ਘੱਟ ਦੇਖਿਆ ਗਿਆ ਸੀ; ਅਕਸਰ ਇਹ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਸੀ। ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਅਸੀਂ ਡਿਫੌਲਟ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਦੀਆਂ ਤਰਜੀਹਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਹਰੇਕ ਪਾਲਿਸੀ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡੀਬੱਗ ਨਹੀਂ ਕਰ ਸਕੇ, ਸਾਨੂੰ ਪੌਡ ਸ਼ਡਿਊਲਿੰਗ ਨੀਤੀਆਂ ਦੇ ਲਚਕਦਾਰ ਪ੍ਰਬੰਧਨ ਦੀ ਲੋੜ ਸੀ।

ਸਮੱਸਿਆ ਦਾ ਗਠਨ

ਅਸੀਂ ਚਾਹੁੰਦੇ ਸੀ ਕਿ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਖਾਸ ਹੋਵੇ, ਯਾਨੀ ਕਿ, ਕੁਬਰਨੇਟਸ ਦੀਆਂ ਮੁੱਖ ਸੰਸਥਾਵਾਂ (ਇੱਥੇ ਸਾਡਾ ਮਤਲਬ ਡਿਫਾਲਟ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਹੈ) ਨੂੰ ਬਦਲਿਆ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ। ਅਸੀਂ ਕਿਸੇ ਸਮੱਸਿਆ ਨੂੰ ਇੱਕ ਥਾਂ 'ਤੇ ਹੱਲ ਕਰਕੇ ਦੂਜੀ ਥਾਂ 'ਤੇ ਬਣਾਉਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ ਸੀ। ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਦੋ ਵਿਕਲਪਾਂ 'ਤੇ ਆਏ, ਜੋ ਲੇਖ ਦੀ ਜਾਣ-ਪਛਾਣ ਵਿੱਚ ਘੋਸ਼ਿਤ ਕੀਤੇ ਗਏ ਸਨ - ਇੱਕ ਵਾਧੂ ਸ਼ਡਿਊਲਰ ਬਣਾਉਣਾ ਜਾਂ ਆਪਣਾ ਖੁਦ ਦਾ ਲਿਖਣਾ। ਕ੍ਰੋਨ ਕਾਰਜਾਂ ਨੂੰ ਤਹਿ ਕਰਨ ਲਈ ਮੁੱਖ ਲੋੜ ਤਿੰਨ ਨੋਡਾਂ ਵਿੱਚ ਸਮਾਨ ਰੂਪ ਵਿੱਚ ਲੋਡ ਨੂੰ ਵੰਡਣਾ ਹੈ। ਇਸ ਲੋੜ ਨੂੰ ਮੌਜੂਦਾ ਕਿਊਬ-ਸਡਿਊਲਰ ਨੀਤੀਆਂ ਦੁਆਰਾ ਪੂਰਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਸਾਡੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਆਪਣੇ ਖੁਦ ਦੇ ਸ਼ਡਿਊਲਰ ਨੂੰ ਲਿਖਣ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ।

ਇੱਕ ਵਾਧੂ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਬਣਾਉਣ ਅਤੇ ਤੈਨਾਤ ਕਰਨ ਲਈ ਹਦਾਇਤਾਂ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ ਦਸਤਾਵੇਜ਼. ਹਾਲਾਂਕਿ, ਇਹ ਸਾਨੂੰ ਜਾਪਦਾ ਸੀ ਕਿ ਡਿਪਲਾਇਮੈਂਟ ਇਕਾਈ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਵਰਗੀ ਨਾਜ਼ੁਕ ਸੇਵਾ ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਸੀ, ਇਸਲਈ ਅਸੀਂ ਇੱਕ ਨਵੇਂ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਨੂੰ ਇੱਕ ਸਟੈਟਿਕ ਪੋਡ ਵਜੋਂ ਤਾਇਨਾਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਜਿਸਦੀ ਸਿੱਧੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਵੇਗੀ। ਕੁਬੇਲੇਟ ਦੁਆਰਾ. ਇਸ ਤਰ੍ਹਾਂ, ਸਾਡੇ ਕੋਲ ਨਵੇਂ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਲਈ ਹੇਠ ਲਿਖੀਆਂ ਲੋੜਾਂ ਹਨ:

1. ਸੇਵਾ ਨੂੰ ਸਾਰੇ ਕਲੱਸਟਰ ਮਾਸਟਰਾਂ 'ਤੇ ਸਟੈਟਿਕ ਪੌਡ ਵਜੋਂ ਤਾਇਨਾਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ
2. ਕਸੂਰ ਸਹਿਣਸ਼ੀਲਤਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ ਜੇਕਰ ਕਿਊਬ-ਸਡਿਊਲਰ ਦੇ ਨਾਲ ਕਿਰਿਆਸ਼ੀਲ ਪੌਡ ਉਪਲਬਧ ਨਾ ਹੋਵੇ
3. ਯੋਜਨਾ ਬਣਾਉਣ ਵੇਲੇ ਮੁੱਖ ਤਰਜੀਹ ਨੋਡ 'ਤੇ ਉਪਲਬਧ ਸਰੋਤਾਂ ਦੀ ਗਿਣਤੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (LeastRequestedPriority)

ਲਾਗੂ ਕਰਨ ਦੇ ਹੱਲ

ਇਹ ਤੁਰੰਤ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਅਸੀਂ ਕੁਬਰਨੇਟਸ v1.14.7 ਵਿੱਚ ਸਾਰਾ ਕੰਮ ਕਰਾਂਗੇ, ਕਿਉਂਕਿ ਇਹ ਉਹ ਸੰਸਕਰਣ ਹੈ ਜੋ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ ਸੀ। ਆਉ ਆਪਣੇ ਨਵੇਂ ਕੁਬੇ-ਸਡਿਊਲਰ ਲਈ ਮੈਨੀਫੈਸਟੋ ਲਿਖ ਕੇ ਸ਼ੁਰੂਆਤ ਕਰੀਏ। ਚਲੋ ਡਿਫਾਲਟ ਮੈਨੀਫੈਸਟ (/etc/kubernetes/manifests/kube-scheduler.yaml) ਨੂੰ ਆਧਾਰ ਵਜੋਂ ਲੈਂਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਫਾਰਮ ਵਿੱਚ ਲਿਆਉਂਦੇ ਹਾਂ:

kind: Pod
metadata:
  labels:
    component: scheduler
    tier: control-plane
  name: kube-scheduler-cron
  namespace: kube-system
spec:
      containers:
      - command:
        - /usr/local/bin/kube-scheduler
        - --address=0.0.0.0
        - --port=10151
        - --secure-port=10159
        - --config=/etc/kubernetes/scheduler-custom.conf
        - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
        - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
        - --v=2
        image: gcr.io/google-containers/kube-scheduler:v1.14.7
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 8
          httpGet:
            host: 127.0.0.1
            path: /healthz
            port: 10151
            scheme: HTTP
          initialDelaySeconds: 15
          timeoutSeconds: 15
        name: kube-scheduler-cron-container
        resources:
          requests:
            cpu: '0.1'
        volumeMounts:
        - mountPath: /etc/kubernetes/scheduler.conf
          name: kube-config
          readOnly: true
        - mountPath: /etc/localtime
          name: localtime
          readOnly: true
        - mountPath: /etc/kubernetes/scheduler-custom.conf
          name: scheduler-config
          readOnly: true
        - mountPath: /etc/kubernetes/scheduler-custom-policy-config.json
          name: policy-config
          readOnly: true
      hostNetwork: true
      priorityClassName: system-cluster-critical
      volumes:
      - hostPath:
          path: /etc/kubernetes/scheduler.conf
          type: FileOrCreate
        name: kube-config
      - hostPath:
          path: /etc/localtime
        name: localtime
      - hostPath:
          path: /etc/kubernetes/scheduler-custom.conf
          type: FileOrCreate
        name: scheduler-config
      - hostPath:
          path: /etc/kubernetes/scheduler-custom-policy-config.json
          type: FileOrCreate
        name: policy-config

ਮੁੱਖ ਤਬਦੀਲੀਆਂ ਬਾਰੇ ਸੰਖੇਪ ਵਿੱਚ:

1. ਪੌਡ ਅਤੇ ਕੰਟੇਨਰ ਦਾ ਨਾਮ kube-scheduler-cron ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ
2. ਵਿਕਲਪ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਗਏ ਪੋਰਟਾਂ 10151 ਅਤੇ 10159 ਦੀ ਵਰਤੋਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤਾ hostNetwork: true ਅਤੇ ਅਸੀਂ ਡਿਫਾਲਟ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ (10251 ਅਤੇ 10259) ਦੇ ਰੂਪ ਵਿੱਚ ਉਹੀ ਪੋਰਟਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਾਂ।
3. --config ਪੈਰਾਮੀਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਸੰਰਚਨਾ ਫਾਇਲ ਨਿਰਧਾਰਤ ਕੀਤੀ ਹੈ ਜਿਸ ਨਾਲ ਸੇਵਾ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਣੀ ਹੈ
4. ਹੋਸਟ ਤੋਂ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲ (scheduler-custom.conf) ਅਤੇ ਸਮਾਂ-ਸਾਰਣੀ ਨੀਤੀ ਫਾਈਲ (scheduler-custom-policy-config.json) ਦੀ ਸੰਰਚਨਾ ਕੀਤੀ ਮਾਊਂਟਿੰਗ

ਇਹ ਨਾ ਭੁੱਲੋ ਕਿ ਸਾਡੇ ਕਿਊਬ-ਸਡਿਊਲਰ ਨੂੰ ਡਿਫੌਲਟ ਵਾਂਗ ਹੀ ਅਧਿਕਾਰਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਇਸਦੀ ਕਲੱਸਟਰ ਭੂਮਿਕਾ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰੋ:

kubectl edit clusterrole system:kube-scheduler

...
   resourceNames:
    - kube-scheduler
    - kube-scheduler-cron
...

ਹੁਣ ਆਓ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰੀਏ ਕਿ ਸੰਰਚਨਾ ਫਾਈਲ ਅਤੇ ਸਮਾਂ-ਸਾਰਣੀ ਨੀਤੀ ਫਾਈਲ ਵਿੱਚ ਕੀ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਸੰਰਚਨਾ ਫਾਇਲ (scheduler-custom.conf)
  ਡਿਫਾਲਟ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਸੰਰਚਨਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪੈਰਾਮੀਟਰ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ --write-config-to ਤੱਕ ਦਸਤਾਵੇਜ਼. ਅਸੀਂ ਨਤੀਜੇ ਵਾਲੀ ਸੰਰਚਨਾ ਨੂੰ ਫਾਈਲ /etc/kubernetes/scheduler-custom.conf ਵਿੱਚ ਰੱਖਾਂਗੇ ਅਤੇ ਇਸਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਫਾਰਮ ਵਿੱਚ ਘਟਾਵਾਂਗੇ:

apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
schedulerName: kube-scheduler-cron
bindTimeoutSeconds: 600
clientConnection:
  acceptContentTypes: ""
  burst: 100
  contentType: application/vnd.kubernetes.protobuf
  kubeconfig: /etc/kubernetes/scheduler.conf
  qps: 50
disablePreemption: false
enableContentionProfiling: false
enableProfiling: false
failureDomains: kubernetes.io/hostname,failure-domain.beta.kubernetes.io/zone,failure-domain.beta.kubernetes.io/region
hardPodAffinitySymmetricWeight: 1
healthzBindAddress: 0.0.0.0:10151
leaderElection:
  leaderElect: true
  leaseDuration: 15s
  lockObjectName: kube-scheduler-cron
  lockObjectNamespace: kube-system
  renewDeadline: 10s
  resourceLock: endpoints
  retryPeriod: 2s
metricsBindAddress: 0.0.0.0:10151
percentageOfNodesToScore: 0
algorithmSource:
   policy:
     file:
       path: "/etc/kubernetes/scheduler-custom-policy-config.json"

ਮੁੱਖ ਤਬਦੀਲੀਆਂ ਬਾਰੇ ਸੰਖੇਪ ਵਿੱਚ:

1. ਅਸੀਂ ਸਾਡੀ ਕਿਊਬ-ਸਡਿਊਲਰ-ਕ੍ਰੋਨ ਸੇਵਾ ਦੇ ਨਾਮ ਲਈ ਸ਼ੈਡਿਊਲਰ ਨਾਮ ਸੈੱਟ ਕੀਤਾ ਹੈ।
2. ਪੈਰਾਮੀਟਰ ਵਿੱਚ lockObjectName ਤੁਹਾਨੂੰ ਸਾਡੀ ਸੇਵਾ ਦਾ ਨਾਮ ਵੀ ਸੈੱਟ ਕਰਨ ਅਤੇ ਪੈਰਾਮੀਟਰ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ leaderElect ਸਹੀ 'ਤੇ ਸੈੱਟ ਕਰੋ (ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਮਾਸਟਰ ਨੋਡ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਗਲਤ 'ਤੇ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ)।
3. ਪੈਰਾਮੀਟਰ ਵਿੱਚ ਸਮਾਂ-ਸਾਰਣੀ ਨੀਤੀਆਂ ਦੇ ਵਰਣਨ ਦੇ ਨਾਲ ਫਾਈਲ ਦਾ ਮਾਰਗ ਨਿਸ਼ਚਿਤ ਕੀਤਾ algorithmSource.

ਦੂਜੇ ਬਿੰਦੂ 'ਤੇ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰਨ ਦੇ ਯੋਗ ਹੈ, ਜਿੱਥੇ ਅਸੀਂ ਕੁੰਜੀ ਲਈ ਮਾਪਦੰਡਾਂ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਦੇ ਹਾਂ leaderElection. ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ ਸਮਰੱਥ ਕੀਤਾ ਹੈ (leaderElect(resourceLock) ਨਾਮਕ kube-scheduler-cron (lockObjectName) ਕੁਬੇ-ਸਿਸਟਮ ਨਾਮ-ਸਥਾਨ ਵਿੱਚ (lockObjectNamespace). ਕੁਬਰਨੇਟਸ ਮੁੱਖ ਭਾਗਾਂ (ਕੁਬੇ-ਸ਼ਡਿਊਲਰ ਸਮੇਤ) ਦੀ ਉੱਚ ਉਪਲਬਧਤਾ ਨੂੰ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ, ਇਸ ਵਿੱਚ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਲੇਖ.

• ਤਹਿ ਨੀਤੀ ਫਾਈਲ (scheduler-custom-policy-config.json)
  ਜਿਵੇਂ ਕਿ ਮੈਂ ਪਹਿਲਾਂ ਲਿਖਿਆ ਸੀ, ਅਸੀਂ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹਾਂ ਕਿ ਡਿਫਾਲਟ ਕਿਊਬ-ਸਡਿਊਲਰ ਕਿਹੜੀਆਂ ਖਾਸ ਨੀਤੀਆਂ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਸਿਰਫ਼ ਇਸਦੇ ਕੋਡ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਕੇ। ਭਾਵ, ਅਸੀਂ ਡਿਫਾਲਟ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਲਈ ਸਮਾਂ-ਸਾਰਣੀ ਨੀਤੀਆਂ ਵਾਲੀ ਇੱਕ ਫਾਈਲ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ ਇੱਕ ਸੰਰਚਨਾ ਫਾਈਲ. ਆਉ ਹੇਠਾਂ ਦਿੱਤੇ ਅਨੁਸਾਰ /etc/kubernetes/scheduler-custom-policy-config.json ਫਾਈਲ ਵਿੱਚ ਸ਼ਡਿਊਲਿੰਗ ਨੀਤੀਆਂ ਦਾ ਵਰਣਨ ਕਰੀਏ:

{
  "kind": "Policy",
  "apiVersion": "v1",
  "predicates": [
    {
      "name": "GeneralPredicates"
    }
  ],
  "priorities": [
    {
      "name": "ServiceSpreadingPriority",
      "weight": 1
    },
    {
      "name": "EqualPriority",
      "weight": 1
    },
    {
      "name": "LeastRequestedPriority",
      "weight": 1
    },
    {
      "name": "NodePreferAvoidPodsPriority",
      "weight": 10000
    },
    {
      "name": "NodeAffinityPriority",
      "weight": 1
    }
  ],
  "hardPodAffinitySymmetricWeight" : 10,
  "alwaysCheckAllPredicates" : false
}

ਇਸ ਤਰ੍ਹਾਂ, ਕਿਊਬ-ਸਡਿਊਲਰ ਪਹਿਲਾਂ ਨੋਡਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਕੰਪਾਇਲ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਪੌਡ ਨੂੰ GeneralPredicates ਪਾਲਿਸੀ (ਜਿਸ ਵਿੱਚ PodFitsResources, PodFitsHostPorts, HostName, ਅਤੇ MatchNodeSelector ਪਾਲਿਸੀਆਂ ਦਾ ਇੱਕ ਸੈੱਟ ਸ਼ਾਮਲ ਹੈ) ਦੇ ਅਨੁਸਾਰ ਤਹਿ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਅਤੇ ਫਿਰ ਹਰੇਕ ਨੋਡ ਦਾ ਮੁਲਾਂਕਣ ਤਰਜੀਹਾਂ ਐਰੇ ਵਿੱਚ ਨੀਤੀਆਂ ਦੇ ਸੈੱਟ ਦੇ ਅਨੁਸਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਾਡੇ ਕੰਮ ਦੀਆਂ ਸ਼ਰਤਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਸੋਚਿਆ ਕਿ ਅਜਿਹੀਆਂ ਨੀਤੀਆਂ ਦਾ ਸੈੱਟ ਸਰਵੋਤਮ ਹੱਲ ਹੋਵੇਗਾ। ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣ ਦਿਓ ਕਿ ਉਹਨਾਂ ਦੇ ਵਿਸਤ੍ਰਿਤ ਵਰਣਨ ਦੇ ਨਾਲ ਨੀਤੀਆਂ ਦਾ ਇੱਕ ਸੈੱਟ ਵਿੱਚ ਉਪਲਬਧ ਹੈ ਦਸਤਾਵੇਜ਼. ਆਪਣੇ ਕੰਮ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਵਰਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਨੀਤੀਆਂ ਦੇ ਸੈੱਟ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਉਚਿਤ ਵਜ਼ਨ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ।

ਚਲੋ ਨਵੇਂ kube-scheduler ਦੇ ਮੈਨੀਫੈਸਟ ਨੂੰ ਕਾਲ ਕਰੀਏ, ਜਿਸ ਨੂੰ ਅਸੀਂ ਚੈਪਟਰ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਬਣਾਇਆ ਹੈ, kube-scheduler-custom.yaml ਅਤੇ ਇਸਨੂੰ ਤਿੰਨ ਮਾਸਟਰ ਨੋਡਾਂ 'ਤੇ ਹੇਠਾਂ ਦਿੱਤੇ ਮਾਰਗ /etc/kubernetes/manifests ਵਿੱਚ ਰੱਖੋ। ਜੇਕਰ ਸਭ ਕੁਝ ਸਹੀ ਢੰਗ ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੁਬੇਲੇਟ ਹਰੇਕ ਨੋਡ 'ਤੇ ਇੱਕ ਪੌਡ ਲਾਂਚ ਕਰੇਗਾ, ਅਤੇ ਸਾਡੇ ਨਵੇਂ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਦੇ ਲੌਗਸ ਵਿੱਚ ਅਸੀਂ ਜਾਣਕਾਰੀ ਦੇਖਾਂਗੇ ਕਿ ਸਾਡੀ ਨੀਤੀ ਫਾਈਲ ਸਫਲਤਾਪੂਰਵਕ ਲਾਗੂ ਕੀਤੀ ਗਈ ਸੀ:

Creating scheduler from configuration: {{ } [{GeneralPredicates <nil>}] [{ServiceSpreadingPriority 1 <nil>} {EqualPriority 1 <nil>} {LeastRequestedPriority 1 <nil>} {NodePreferAvoidPodsPriority 10000 <nil>} {NodeAffinityPriority 1 <nil>}] [] 10 false}
Registering predicate: GeneralPredicates
Predicate type GeneralPredicates already registered, reusing.
Registering priority: ServiceSpreadingPriority
Priority type ServiceSpreadingPriority already registered, reusing.
Registering priority: EqualPriority
Priority type EqualPriority already registered, reusing.
Registering priority: LeastRequestedPriority
Priority type LeastRequestedPriority already registered, reusing.
Registering priority: NodePreferAvoidPodsPriority
Priority type NodePreferAvoidPodsPriority already registered, reusing.
Registering priority: NodeAffinityPriority
Priority type NodeAffinityPriority already registered, reusing.
Creating scheduler with fit predicates 'map[GeneralPredicates:{}]' and priority functions 'map[EqualPriority:{} LeastRequestedPriority:{} NodeAffinityPriority:{} NodePreferAvoidPodsPriority:{} ServiceSpreadingPriority:{}]'

ਹੁਣ ਸਾਡੇ ਕ੍ਰੋਨਜੌਬ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਵਿੱਚ ਇਹ ਦਰਸਾਉਣਾ ਬਾਕੀ ਹੈ ਕਿ ਇਸ ਦੀਆਂ ਪੌਡਾਂ ਨੂੰ ਤਹਿ ਕਰਨ ਦੀਆਂ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸਾਡੇ ਨਵੇਂ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਦੁਆਰਾ ਸੰਸਾਧਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:

...
 jobTemplate:
    spec:
      template:
        spec:
          schedulerName: kube-scheduler-cron
...

ਸਿੱਟਾ

ਆਖਰਕਾਰ, ਸਾਨੂੰ ਅਨੁਸੂਚਿਤ ਨੀਤੀਆਂ ਦੇ ਇੱਕ ਵਿਲੱਖਣ ਸੈੱਟ ਦੇ ਨਾਲ ਇੱਕ ਵਾਧੂ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਮਿਲਿਆ, ਜਿਸ ਦੇ ਕੰਮ ਦੀ ਨਿਗਰਾਨੀ ਸਿੱਧੇ ਕੁਬੇਲੇਟ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਆਪਣੇ ਕੁਬੇ-ਸਡਿਊਲਰ ਦੀਆਂ ਪੌਡਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਨਵੇਂ ਨੇਤਾ ਦੀ ਚੋਣ ਸਥਾਪਤ ਕੀਤੀ ਹੈ ਜੇਕਰ ਪੁਰਾਣਾ ਨੇਤਾ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਅਣਉਪਲਬਧ ਹੋ ਜਾਂਦਾ ਹੈ.

ਨਿਯਮਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਨੂੰ ਡਿਫੌਲਟ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਦੁਆਰਾ ਤਹਿ ਕੀਤਾ ਜਾਣਾ ਜਾਰੀ ਹੈ, ਅਤੇ ਸਾਰੇ ਕ੍ਰੋਨ ਕਾਰਜਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਵੇਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਕ੍ਰੋਨ ਟਾਸਕ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਲੋਡ ਹੁਣ ਸਾਰੇ ਨੋਡਾਂ ਵਿੱਚ ਬਰਾਬਰ ਵੰਡਿਆ ਗਿਆ ਹੈ। ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ ਜ਼ਿਆਦਾਤਰ ਕ੍ਰੋਨ ਕਾਰਜਾਂ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਦੇ ਮੁੱਖ ਕਾਰਜਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਉਸੇ ਨੋਡਾਂ 'ਤੇ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਨਾਲ ਸਰੋਤਾਂ ਦੀ ਘਾਟ ਕਾਰਨ ਪੌਡਾਂ ਨੂੰ ਹਿਲਾਉਣ ਦੇ ਜੋਖਮ ਨੂੰ ਕਾਫ਼ੀ ਘਟਾਇਆ ਗਿਆ ਹੈ। ਵਾਧੂ ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਕ੍ਰੋਨ ਕਾਰਜਾਂ ਦੀ ਅਸਮਾਨ ਸਮਾਂ-ਸਾਰਣੀ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੁਣ ਪੈਦਾ ਨਹੀਂ ਹੋਈਆਂ।

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਹੋਰ ਲੇਖ ਵੀ ਪੜ੍ਹੋ:

• ਕੈਲੀਕੋ ਦੇ ਨਾਲ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਪ੍ਰਬੰਧਨ
• ਕੈਲੀਕੋ ਦੇ ਨਾਲ ਨੈੱਟਵਰਕ ਨੀਤੀ ਵਿਕਲਪਾਂ ਨੂੰ ਸਮਝਣਾ
• ਜਦੋਂ ਲੀਨਕਸ ਕੰਟਰੈਕ ਹੁਣ ਤੁਹਾਡਾ ਦੋਸਤ ਨਹੀਂ ਰਿਹਾ
• iota ਟ੍ਰਾਂਸਫਰ ਦੀਆਂ 4 ਉਦਾਹਰਣਾਂ
• ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਿਨਾਂ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨਾ
• ਜ਼ੀਰੋ ਡਾਊਨਟਾਈਮ ਡਿਪਲਾਇਮੈਂਟ ਅਤੇ ਡਾਟਾਬੇਸ
• ਕੁਬਰਨੇਟਸ: ਸਿਸਟਮ ਸਰੋਤ ਪ੍ਰਬੰਧਨ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਇੰਨਾ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ?

ਸਰੋਤ: www.habr.com