klog Level Standardization

[kr11]

Pull Request Description

[Please provide a clear and concise description of your changes here]

Changes

1. Adjusted log levels from V(3) and V(5) to V(4) or V(2), and removed V(2) since it is the default output level.
2. Simplified Fatal usage, e.g., klog.Fatal(err.Error()) -> klog.Fatal(err).
3. Changed klog.Info to use klog.InfoS for consistency and extensibility. If additional context information needs to be added in the future, it can be easily done by appending key-value pair parameters to the InfoS.

Open Questions

1. We noticed that most places use "k8s.io/klog/v2", but some places (e.g., pkg/cache/cache.go) use "k8s.io/klog". Should we standardize on one version of klog throughout the codebase?

2. In pkg/controller/util/expectation/expectation.go:

   klog.V(2).Info("Error encountered while checking expectations, forcing sync", "err", err)
   klog.Warning("Error encountered while checking expectations, forcing sync", "err", err)

   Should we use klog.Warning or klog.Info for this case? What's the best practice?

References

• Kubernetes Contributors Logging Guidelines: kubernetes/logging.md

Related Issues

Resolves: #69

Important: Before submitting, please complete the description above and review the checklist below.

---

Contribution Guidelines (Expand for Details)

We appreciate your contribution to aibrix! To ensure a smooth review process and maintain high code quality, please adhere to the following guidelines:

Pull Request Title Format

Your PR title should start with one of these prefixes to indicate the nature of the change:

• [Bug]: Corrections to existing functionality
• [CI]: Changes to build process or CI pipeline
• [Docs]: Updates or additions to documentation
• [API]: Modifications to aibrix's API or interface
• [CLI]: Changes or additions to the Command Line Interface
• [Misc]: For changes not covered above (use sparingly)

Note: For changes spanning multiple categories, use multiple prefixes in order of importance.

Submission Checklist

• PR title includes appropriate prefix(es)
• Changes are clearly explained in the PR description
• New and existing tests pass successfully
• Code adheres to project style and best practices
• Documentation updated to reflect changes (if applicable)
• Thorough testing completed, no regressions introduced

By submitting this PR, you confirm that you've read these guidelines and your changes align with the project's contribution standards.

[Jeffwan]

the change looks good to me.