Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Configuration #1007

Closed
wants to merge 1 commit into from
Closed

Proposal: Configuration #1007

wants to merge 1 commit into from

Conversation

bgrant0607
Copy link
Member

@smarterclayton
Starting point for discussion. Feedback welcome. Also let me know where you'd like more detail.

@brendandburns
Copy link
Contributor

I think this generally captures the things we want, but I think that having a number of real-world examples of things like the generator, would go a long way to making some of the concrete concepts more tangible.


## Decomposing the configuration process

Where possible, the Docker image should be used to configuration of Docker and the Linux environment known at build time, such as exposed ports, expected volumes, the entry point, capabilities required for correct operation of the application, and so on. This document will focus on configuration of objects managed by Kubernetes and its ecosystem.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the Docker image should be used to configuration of Docker and the Linux environment

to configure?


Furthermore, with Kubernetes, we’re trying to encourage an open ecosystem of composable systems and layered APIs. Kubernetes will also support plug-ins for a variety of functionality. If you find your use case requires complex configuration transformations, that suggests a missing ecosystem component or plug-in. We encourage you to help the community build that missing mechanism as opposed to proliferating the use of fragile configuration generation logic.

For example, a common need is to specify instance-specific behavior. Rather than attempting to statically configure such behavior, one could build a runtime task-assignment service, which would be resilient to pod and host failures.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed #1064 to remind us to try this pattern.

@smarterclayton smarterclayton changed the title First draft of configuration proposal. Proposal: Configuration Sep 2, 2014
@bgrant0607
Copy link
Member Author

I found editing the huge .md file to be unwieldy. I'm going to break this proposal into smaller issues. I already filed #1178, which generated lots more feedback than this PR.

@bgrant0607 bgrant0607 mentioned this pull request Jan 20, 2015
b3atlesfan pushed a commit to b3atlesfan/kubernetes that referenced this pull request Feb 5, 2021
edit Flannel license info so that GitHub recognizes it
mfojtik pushed a commit to mfojtik/kubernetes that referenced this pull request Oct 8, 2021
…ated_pods_openshift

Bug 2011513: kubelet: do not arbitrarily create a podSyncStatus for finished pods
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/app-lifecycle kind/design Categorizes issue or PR as related to design.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants