DevOps KB Pages

Affinity rules in Kubernetes are constraints that influence the scheduling of pods based on certain conditions. These rules help you control the placement of pods on nodes or in relation to other pods, ensuring optimal performance, resource utilization, and reliability. Affinity rules come in three main types: node affinity , pod affinity , and pod anti-affinity . Practical Use Cases Node Affinity: Ensuring pods with high memory requirements are scheduled on nodes with high memory capacity. Pod Affinity: Scheduling web servers close to caching servers to reduce latency. Pod Anti-Affinity: Spreading replicas of a service across different nodes to ensure high availability. By using affinity and anti-affinity rules, Kubernetes administrators can fine-tune pod scheduling to meet specific application requirements and optimize the cluster's overall performance. Ref: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector

How Taints and Tolerations Work Together:  Taint: Applied to nodes to indicate that they should repel certain pods. Toleration: Applied to pods to indicate that they can be scheduled on nodes with matching taints. Importance of Matching Effects The effect in the toleration must exactly match the effect in the taint for the toleration to work. If they do not match, the toleration will not counteract the taint, and the pod will be treated as if it has no toleration for that taint. For a toleration to work, the effect field in the toleration must match the effect field in the taint on the node. If they do not match, the toleration will not counteract the taint, and the pod will not be scheduled on the node. When you exclude the effect field in a toleration, the toleration matches any taint with the specified key and value, regardless of the effect. This is a shorthand way of writing a toleration that matches taints with any effect. Ref: https://kubernetes.io/docs/concepts/sche...

man: lsof - list open files lsof -n | grep rundeck |wc -l lsof -n | grep rundeck | grep deleted | wc -l lsof -n | grep rundeck | grep deleted lsof -p 21601 | wc -l lsof -p 21601 | grep deleted | wc -l #Find out proc limits ps -aux|grep java cat /proc/1208/limits #ps -aux|grep java root      5718  0.0  0.0 182020  2172 ?        S    May02   0:00 runuser -s /bin/bash -l rundeck -c java -Drundeck.jaaslogin=true            -Djava.security.auth.login.config=/etc/rundeck/jaas-ldap.conf            -Dloginmodule.name=ldap            -Drdeck.config=/etc/rundeck            -Drundeck.server.configDir=/etc/rundeck            -Dserver.datastore.path=/var/lib/rundeck/data/rundeck     # cat /proc/ 5718 /limits Limit               ...

There is a known limitation with MSBuild when there is a referenced project has nested referenced project from another solution, MSBuild will fail but the same SLN will work fine from the Visual Studio IDE since VS works a little differently.  This is an unfortunate behavior. We wish the behavior for a ProjectReference to a not-in-the-solution project was to inherit the Configuration of the project that references it, to avoid this confusion. However, this could result in confusing behavior of its own: the not-in-solution project could be built multiple times (in parallel) with different configurations. Since we currently build only once, adding the possibility of parallel builds (and just changing the configuration of the not-in-solution project) could break users, so we're unwilling to make this change now. The current behavior can be worked around by explicitly specifying the configuration using SetConfiguration metadata or by adding the referenced project to the solution. Refer...

The "Sleepstudy" option from the PowerCfg.exe cmd generates a pretty cool power state report for your machine where you can see how many times the machine went to sleep, the screen went offline, and much more... powercfg /sleepstudy https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/powercfg-command-line-options#option_sleepstudy

PackageManagement and PowerShellGet, which operate within Windows. PackageManagement acts as a framework for package delivery, while PowerShellGet is a module within PackageManagement specifically for managing PowerShell packages. Here's a condensed breakdown: PackageManagement : It's a framework for package delivery in Windows. Administered through PowerShell. Consists of PackageProviders (like package managers) and PackageSources (where providers get packages). PowerShellGet : A PowerShell module using PackageManagement for delivering PowerShell packages. Utilizes PSRepositories (virtual wrappers for PackageSources). Manages modules and scripts from sources like PowerShell Gallery. Facilitates package installation, updating, and publishing. Summary : PSRepository serves as a wrapper for PackageSource. PSRepository has custom properties for managing URIs. PowerShellGet uses PackageManagement in the background. PowerShellGet registers itself as a PackageProvider and interacts w...

Investigate actions on Azure Kubernetes Service using Auditing https://itnext.io/whodunit-investigate-actions-on-aks-using-auditing-1db3ccf9ae86